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EXECUTIVE  SUMMARY 


The  Logistics  Analysis  and  Wargame  Support  Tool  (LAWST)  was  developed  for 
the  Marine  Corps  Expeditionary  Energy  Office  (E20)  to  use  during  the  Expeditionary 
Force  (EF)-21  Energy  Study  Operational  Reach  Wargame  in  2015.  The  primary  focus  of 
the  LAWST  is  to  examine  the  fuel  consumption  of  the  logistics  network  to  better 
understand  the  total  energy  demand  of  all  forces  operating  in  some  area  of  operations.  The 
Logistics  Analysis  and  Wargame  Support  Tool  is  designed  to  complement  the  Marine  Air- 
Ground  Task  Force  (MAGTF)  Power  and  Energy  Model  (MPEM),  which  models  the 
energy  consumption  of  various  Marine  Corps  formations  while  deployed,  whereas  LAWST 
specifically  examines  the  logistics  network  that  supports  those  formations.  However,  a 
previous  study  reveals  that  LAWST  does  not  satisfy  stakeholder  objectives  and  is  in  poor 
position  to  pass  verification  and  validation  needs.  Findings  from  this  past  study  stem  from 
the  vague  definition  of  the  system  requirements. 

Our  research  focuses  on  the  system  requirements  for  LAWST.  The  three  primary 
objectives  of  the  research  are:  to  determine  how  the  system  requirements  for  LAWST  were 
established,  to  determine  what  the  requirements  for  LAWST  would  be  had  a  systems 
engineering  approach  been  used,  and  to  determine  the  extent  to  which  LAWST  would  meet 
requirements  developed  using  a  systems  engineering  approach.  Additionally,  the  research 
compares  the  original  requirements  to  a  set  of  requirements  developed  using  a  systems 
engineering  approach.  It  quantifies  the  difference  in  the  two  requirements  sets.  These 
requirements  are  the  key  link  in  the  validity  of  the  current  system  in  meeting  its  original 
purpose. 

The  original  purpose  for  LAWST  is  not  explicitly  articulated.  However,  there  are 
eight  presumed  requirements  that  could  be  found  in  informal  documents  provided  by  E20 
and  the  primary  contractor  for  the  system.  The  process  used  to  develop  those  requirements 
is  unclear,  but  the  most  direct  linkages  are  to  the  questions  posed  in  the  EF-21  Energy 
Study  and  Operational  Reach  Wargame.  LAWST  meets  four  of  the  eight  requirements  and 
partially  meets  three  others.  There  is  little  evidence  that  these  presumed  requirements  are 
for  the  current  version  of  LAWST  and  no  trade-off  analysis  for  any  of  these  requirements. 
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There  is  no  documented  proof  that  LAWST  meets  its  original  purpose.  These  findings  are 
consistent  with  an  internal  report  that  the  Naval  Postgraduate  School  provided  to  E20.  The 
report  focused  on  the  readiness  of  LAWST  to  undergo  a  verification  and  validation 
process. 

A  set  of  requirements  was  developed  using  a  systems  engineering  approach.  That 
approach  consisted  of  defining  the  problem,  analyzing  the  system’s  mission,  determining 
the  functions  that  the  system  needs  to  perform  while  conducting  the  mission,  and 
developing  requirements  based  on  the  mission  and  functional  analysis.  The  process  led  to  a 
set  of  45  unique  and  traceable  requirements  that  mapped  back  to  the  problem  statement 
derived  from  needs  and  desires  of  the  E20. 

The  requirements  developed  using  a  systems  engineering  approach  differ 
significantly  from  the  original  requirements  for  LAWST  in  both  quantity  and  type.  Most 
notably,  the  requirements  developed  using  a  systems  engineering  approach  include 
nonfunctional  requirements  such  as  usability  and  interoperability  as  well  as  other  functional 
requirement  types,  such  as  optimization.  LAWST  could  meet  24  of  those  45  requirements, 
but  only  partially  meet  the  usability,  interoperability,  and  optimization  requirements. 
Additionally,  as  demonstrated  using  LAWST  as  an  example  in  this  research,  the  increased 
cost  of  developing  a  system  with  incomplete  requirements  and  later  changing  those 
requirements  is  generally  more  expensive  than  developing  a  system  using  a  more  complete 
set  of  requirements  in  the  beginning. 

The  primary  recommendation  from  this  research  is  that  E20  adopt  a  more  robust 
process  for  developing  system  requirements  prior  to  committing  additional  resources  to 
those  future  developments.  A  recommended  framework  for  developing  those  requirements 
is  based  on  the  systems  engineering  process,  which  is  also  recommended  by  the 
Government  Accountability  Office  (GAO)  to  reduce  system  costs  due  to  unidentified 
requirements  being  identified  after  a  system  begins  development  (Government 
Accountability  Office  2015). 

The  methodology  of  this  research  is  founded  on  the  systems  engineering  process, 
specifically  the  methods  for  requirements  generation.  The  steps  for  that  method  as  used  in 
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this  thesis  are  problem  definition,  mission  analysis,  functional  analysis  and  developing 
requirements.  Every  system  has  a  purpose  for  its  development,  which  is  summed  up  in  the 
problem  definition  that  is  produced  after  a  careful  analysis  of  the  customer’s  needs.  In  this 
case,  E20  is  looking  for  a  tool  that  will  help  plan,  analyze,  and  optimize  logistics  networks 
for  tactical  units.  The  mission  analysis,  for  the  most  part,  focuses  on  the  environment  where 
a  system  resides  and  tasks  that  an  operator  will  use  the  system  to  perform.  The  functional 
analysis  determines  the  specific  actions  or  functions  that  a  system  must  perform  as 
articulated  by  the  task  in  the  mission  analysis.  This  includes  both  the  tasks  specified  during 
the  mission  analysis  and  tasks  that  are  implied  by  the  environment  and  the  interaction  with 
the  operator  and  other  systems.  The  requirements  are  pulled  directly  from  both  the  mission 
analysis  and  functional  analysis.  Those  45  requirements  produced  in  this  research  are  a 
basis  for  the  development  of  a  system.  Additionally,  it  makes  an  effort  to  clearly  show  the 
requirements  for  the  current  system  and  their  origin  by  examining  the  existing 
documentation  from  LAWST  that  was  provided  by  E20.  The  research  then  outlines  a  brief 
analysis  of  LAWST  showing  the  extent  to  which  the  system  meets  both  sets  of 
requirements  and  where  the  shortcomings  are  for  the  system,  as  well  as  comparing  the 
requirements  sets  to  each  other.  Those  differences  are  quantified  by  comparing  both  the 
resource  investment  needed  to  produce  the  system  and  the  extent  to  which  the  system 
addresses  the  capabilities  that  the  customer  desires  in  the  product. 

Ultimately  the  research  shows  that,  based  on  the  original  requirements,  LAWST  is 
insufficient  to  address  the  tasks  that  E20  wants  it  to  do.  LAWST  does  provide  presumably 
useful  information  in  evaluating  logistics  networks  to  determine  the  additional  energy 
demand  produced  by  the  distribution  of  resources  to  operational  units.  However,  LAWST 
is  not  sufficient  to  support  battalions  and  brigades  in  planning,  analyzing,  and  optimizing 
logistics  networks  during  time-constrained  planning  windows  in  support  of  tactical 
operations. 
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I. 


INTRODUCTION  AND  BACKGROUND 


A.  PURPOSE 

This  research  will  articulate  the  ramifications  to  system  utility  when  a  systems 
engineering  (SE)  approach  is  not  applied  in  requirements  development.  It  will  establish 
an  actionable  framework  to  develop  requirements  that  are  appropriate,  to  the  greatest 
extent  possible,  and  traceable  to  an  overarching  problem  or  gap  for  which  a  system  is 
developed.  Furthermore,  a  system  developed  using  a  systems  engineering  process,  that  is 
verified  to  meet  said  requirements,  is  also  more  likely  to  be  valid  in  addressing  the 
problem  for  which  it  was  developed. 

B.  SCOPE 

The  focus  of  this  research  is  to  examine  the  system  requirements  development 
process  for  LAWST.  The  research  will  examine  the  problem(s)  that  the  system  was 
designed  to  address.  It  will  examine  the  various  uses  for  the  system  and  the  environment 
in  which  it  will  be  used.  Additionally,  it  will  examine  the  various  documents  describing 
modeling,  software,  and  verification  and  validation  (V&V)  within  the  Marine  Corps  and 
DOD  to  determine  additional  considerations  in  the  requirements  generation.  The  specific 
research  questions  that  this  thesis  answers  are  as  follows: 

1.  How  were  the  design  requirements  established  for  the  development  of 
LAWST? 

2.  What  would  the  system  requirements  for  LAWST  be  if  a  systems 
engineering  approach  had  been  used? 

3.  Does  the  current  version  of  LAWST  address  the  system  requirements  that 
would  have  been  developed  through  a  systems  engineering  approach? 

The  boundaries  of  the  problem  (the  use  of  systems  engineering  in  system  design) 
that  this  research  addresses  extend  beyond  the  software  and  documentation  for  LAWST 
and  the  E20’s  specific  issues.  The  problem(s)  that  LAWST  potentially  addresses  impact 
everything  from  strategic  logistic  operations  down  to  the  energy  demands  at  the  company 
level.  It  also  looks  at  the  force  structure  of  the  logistics  elements  that  support  the 

distribution  of  fuel  and  other  supplies  to  the  tactical  edge.  A  number  of  documents 
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outline  guidance  for  modeling  and  simulation  (M&S)  development  and  verification, 
validation,  and  accreditation  (VV&A)  activities  including  MIL-STD-3002 
Documentation  of  VV&A  for  M&S,  DoDI  5000.61  DOD  Modeling  and  Simulation 
(M&S)  Verification,  Validation,  and  Accreditation  (VV&A),  DoDI  5000.59  DOD  M&S 
Management,  SECNAV  Instruction  5200. 38A  and  Marine  Corps  Order  5200. 28A  both 
for  M&S  Management.  LAWST  is  also  subject  to  planning  doctrine  such  as  the  MCWP 
5-1,  Marine  Corps  Planning  Process,  as  it  is  a  tool  that  may  support  wargame  activities 
and  analysis. 

C.  BACKGROUND 

1.  LAWST  Description 

LAWST  is  a  simulation  built  as  a  deterministic  model  to  help  planners  and 
logisticians  ascertain  the  feasibility  of  a  specific  course  of  action  from  a  logistics  supply 
standpoint.  According  to  the  capability  summary,  LAWST  is  “designed  to  assist  with 
operational  planning  and  the  conduct  of  wargames”  (Group  W,  unpublished  document). 
It  models  the  distribution  of  supplies  in  a  given  area  of  operations  with  a  user  defined  set 
of  distribution  assets  and  nodes  within  a  distribution  network  in  order  to  estimate  the 
quantity  of  supplies  (primarily  fuel)  that  will  be  consumed  by  the  logistics  process  itself 
in  servicing  the  supply  needs  of  the  warfighters.  Ligure  1  shows  a  screenshot  of  a 
notional  simulation  scenario. 
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This  shows  a  map  of  the  area  of  operations  along  with  graphs  and  information  related  to 
distribution  assets  and  levels  of  supply. 

Figure  1.  Screen  Shot  of  LAWST  Simulation.  Source:  LAWST  Capability 
Summary  (Group  W,  unpublished  document). 


The  graphical  user  interface  displays  a  map,  or  more  specifically,  an  image  of  a 
map  over-laying  a  latitude/longitude  or  MGRS  reference  system  rather  than  a  geo- 
rectified  map  (LAWST  accepts  image  files  for  this  purpose).  The  user  manually  adds 
locations  for  supply  nodes  and  transportation  (e.g.,  roads)  arcs  between  the  nodes.  While 
the  arcs  do  not  necessarily  follow  known  routes  on  the  map,  the  user  can/may  adjust 
factors  to  reflect  the  distance  and  time  required  to  traverse  the  route  during  various 
operational  conditions.  The  rates  of  consumption  by  tactical  units  (determined  by 
MPEM)  as  well  as  logistics  nodes  are  entered  manually  along  with  type  of  supplies  and 
quantifying  features  of  the  supplies  such  as  weight  and  volume. 

2.  Verification,  Validation,  and  Accreditation 

The  verification,  validation  and  accreditation  (VV&A)  process,  is  a  mechanism 
by  which  models  and  simulations  are  certified  to  be  used  for  some  specific  purpose. 
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Military  Standard  3022,  describing  the  standard  practice  for  the  VV&A  for  models  and 
simulations,  gives  the  following  definitions  for  verification,  validation  and  accreditation: 

Verification.  The  process  of  determining  that  a  model,  simulation,  or 
federation  of  models  and  simulations  implementations  and  their  associated 
data  accurately  represents  the  developer’s  conceptual  description  and 
specifications. 

Validation.  The  process  of  determining  the  degree  to  which  a  model, 
simulation,  or  federation  of  models  and  simulations,  and  their  associated 
data  are  accurate  representations  of  the  real  world  from  the  perspective  of 
the  intended  use(s). 

Accreditation.  The  official  certification  that  a  model,  simulation,  or 
federation  of  models  and  simulations  and  its  associated  data  are  acceptable 
for  use  for  a  specific  purpose.  (Modeling  and  Simulations  Coordination 
Office  2012) 

In  addition,  DOD  Instruction  5000.61  states  that  data  associated  with  M&S  that  is 
used  to  support  DOD  activities  shall  go  through  a  V&V  process  on  a  regular  basis  and  be 
accredited  for  an  intended  use.  Components  are  authorized  to  tailor  the  VV&A  processes 
as  necessary  within  the  guidance  from  the  instruction  (Under  Secretary  of  Defense 
[AT&L]  (USD[AT&L])  (2009)). 

In  2016,  the  Marine  Corps  E20  requested  that  the  Naval  Postgraduate  School 
(NPS)  conduct  an  assessment  of  the  readiness  of  LAWST  to  undergo  a  V&V  process. 
The  report  aimed  to  inform  E20  if  the  simulation  was  ready  to  move  through  a  more 
formal  V&V  process  to  be  accredited  for  use,  and  to  make  recommendations  for 
improvements  to  the  simulation  as  it  is  developed. 

The  V&V  assessment  of  LAWST  is  based  on  implied  current  and  future  uses 
rather  than  on  explicitly  stated  system  requirements  (Hall  2016).  The  implied  uses  are 
based  on  the  current  version  of  LAWST  as  it  exists.  The  V&V  assessment  addresses  the 
question,  “To  what  extent  does  LAWST  do  what  it  does?”  rather  than  the  more  correct 
question:  “To  what  extent  does  LAWST  do  what  it  was  designed  to  do?”  As  stated  in  the 
V&V  assessment: 

The  requirements  that  drove  these  designs  goals  are  neither  specified  here 
nor  characterized  by  how  well  each  of  these  functions  would  need  to  be 
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performed  in  order  to  satisfy  those  requirements  beyond  the  stated  intent 

to  ‘support’  COA  generation  and  live  wargame  support.  (Hall  2016) 

Professor  Hall  describes  how  the  lack  of  formal  requirements  and  specifications  makes  it 
virtually  impossible  to  perform  a  VV&A  assessment  of  the  simulation.  The  absence  of 
traceability  and  objectivity  of  current  capabilities  or  direction  for  future  capabilities  or 
changes  to  the  system  as  it  moves  further  along  in  development  is  a  significant  issue 
(Hall  2016). 

The  set  of  system  requirements  for  the  development  of  LAWST  is  undefined, 
thereby  complicating,  and  perhaps  precluding,  the  ability  to  proceed  with  its  verification 
and  validation.  The  ability  to  establish  use  cases  for  the  end  user  that  could  lead  to  its 
accreditation  is  limited  by  the  lack  of  context  in  which  the  system  was  developed. 
Evidence  of  any  formal  or  documented  process  used  to  generate  system  requirements  for 
the  design  and  development  of  LAWST  is  unknown. 

D.  OBJECTIVES 

This  research  will  determine  the  system  requirements  for  LAWST  using  an  SE 
approach  and  to  what  extent  LAWST  meets  those  requirements.  The  objective  of  this 
research  is  threefold:  to  determine  how  the  system  requirements  for  LAWST  were 
established,  to  determine  what  the  requirements  for  LAWST  would  be  had  a  systems 
engineering  approach  been  used,  and  to  determine  the  extent  to  which  LAWST  would 
meet  requirements  developed  using  a  systems  engineering  approach. 

The  current  instance  of  LAWST  was  developed  to  support  the  EL-21  Operational 
Reach  15  wargame  according  to  Group  W  records.  The  set  of  current  informal  system 
requirements  was  obtained  from  the  Marine  Corps  E20  office  which  oversees  the 
development  of  the  model.  This  informal  approach  to  requirements  development,  that 
will  be  discussed  in  chapter  IV,  section  D,  results  in  a  system  that  is  inadequate  to  meet 
the  needs  of  the  stakeholder. 

Our  results  articulate  the  ramification  of  not  using  a  systems  engineering 
approach  to  requirements  development.  Namely,  LAWST  does  not  meet  E20  system 
objectives.  LAWST  is  not  postured  to  meet  the  demands  of  VV&A  because  there  is  little 
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documentation  on  the  process  used  in  designing  the  system.  Furthermore,  the  E20 
requirements  development  provides  an  inadequate  foundation  for  valid  improvements  to 
LAWST  or  as  a  means  to  assess  the  degree  LAWST  meets  E20  needs. 
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II.  LITERATURE  REVIEW 


System  requirements  come  from  a  variety  of  sources  and  can  be  determined  in  a 
number  of  ways.  The  types  of  requirements  vary  from  system  to  system  and  between 
types  of  systems.  For  instance,  the  requirements  for  a  pen  seem  straight  forward; 
however,  they  may  vary  depending  on  the  context  in  which  the  pen  will  be  used. 
Different  requirements  would  be  necessary  for  a  pen  used  in  space,  as  opposed  to  one 
used  in  a  classroom.  In  other  cases,  two  completely  different  objects  can  have  the  same 
requirements.  A  calculator  and  a  slide  rule  are  vastly  different  objects,  used  for  many  of 
the  same  purposes.  While  requirements  themselves  vary,  requirements  generation  should 
follow  a  logical  process  such  as  systems  engineering,  regardless  of  the  system  or  type  of 
system. 

A.  IMPORTANCE  OF  ACCURATE  REQUIREMENTS 

Accurate  requirements  are  critical  in  every  aspect  of  designing,  building  and 
testing  a  system.  Requirements  that  describe  what  a  system  must  do  and  to  what  degree  it 
will  provide  those  capabilities,  provide  developers  and  testers  with  an  objective  in 
building,  and  measures  to  evaluate  a  system.  In  the  case  of  LAWST,  Professor  Hall 
(2016)  describes  the  validation  as  being  “made  more  difficult”  by  the  lack  of  precision  in 
defining  what  the  system  is  supposed  to  do.  The  conceptual  model  that  is  provided  with 
LAWST  gives  limited  detail  with  respect  to  requirements  other  than  “provide  timely 
analytical  support  to  wargames  in  which  energy  usage  and  distribution  are  of  interest” 
(Group  W,  unpublished  document).  This  statement  does  not  specify  measures  of  how 
fast,  what  type  of  analysis,  or  any  useful  information  in  designing  or  evaluating  the 
system.  More  importantly,  tracing  from  where  this  and  other  system  requirements  are 
derived  is  a  challenge,  but  it  is  worth  the  time  and  effort.  When  a  system  is  developed  to 
a  specific  set  of  requirements  and  delivered  to  the  customer,  it  is  important  that  the 
system  actually  addresses  the  purpose  that  the  customer  desires. 

Blanchard  and  Fabrycky  (2011)  outline  a  method  for  requirements  definition  in 
Figure  2.  It  shows  a  systems  engineering  process  to  decompose  the  problem  into  a  set  of 
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system  specifications  that  can  be  used  for  further  research,  simulation  design,  and 
enhancements.  Central  to  this  approach  is  properly  defining  the  problem  for  which  a 
systems  engineering  approach  is  applied. 
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Figure  2.  System  Requirements  Definition  Process.  Source:  Blanchard  and 

Fabrycky  (2011). 


The  requirements  generation  process  is  the  initial  entry  into  the  Systems 
Engineering  “Vee,”  as  seen  in  Figure  3,  where  the  problem  and  needs  are  decomposed 
into  system  specifications  leading  into  the  design  of  the  system.  System  requirements  are 
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a  critical  component  in  the  design  as  well  as  the  V&V  after  the  system  realization  when  it 
begins  to  take  shape. 


Figure  3.  The  Systems  Engineering  “Vee.”  Adapted  from  Defense  Acquisition 

University  (2017). 


The  systems  engineering  approach  follows  a  logical,  iterative,  and  recursive 
process  that  captures  all  the  aspects  of  the  system  through  its  life  cycle.  The  process  will 
not  only  capture  system  functions  and  measures,  but  also  include  other  system 
interactions,  “-ilities”  (such  as  interoperability,  usability,  supportability),  and  other 
administrative  requirements.  The  SE  requirements  generation  process  ensures  that  often 
overlooked  constraints  on  the  system  design,  derived  from  the  environment  and  other 
external  systems  with  which  it  is  to  operate,  are  considered. 

Current  LAWST  documentation  does  not  confirm  a  specific  problem  definition 
used  to  begin  its  development.  There  are  limited  resources  to  develop  these  types  of  tools, 
and  being  able  to  justify  specific  capabilities  is  important  to  stakeholders.  Therefore,  it  is 
critical  for  this  system  to  be  built  upon  a  solid  foundation  of  an  appropriate  problem 
definition  and  an  accurate  set  of  traceable  requirements.  These  are  the  basis  of  a  credible 
V&V  for  both  the  simulation  and  future  improvements. 

Every  organization  determines  its  own  way  of  generating  requirements  that  suits 
its  timelines,  resources,  and  way  of  doing  business.  Figure  4  outlines  the  Air  Force  Space 
&  Missile  Systems  Center’s  (SMC)  process  for  creating  system  requirements  (2005). 
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Figure  4.  SMC  Requirements  Analysis  Process.  Source:  SMC  (2005). 


This  SMC  process  (Figure  4)  is  quite  similar  to  that  which  Blanchard  and 
Fabrycky  describe  in  Figure  1.  The  verbiage  does  not  quite  line  up  between  the  two 
processes,  but  the  basic  concepts  are  the  same.  Figure  5  maps  the  elements  of  the 
Blanchard  and  Fabrycky  process  to  the  SMC  process. 
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Figure  5.  Comparison  of  SMC  and  Blanchard  and  Fabrycky  Descriptions  of 
Requirements  Generation.  Adapted  from  SMC  (2005)  (right)  and 
Blanchard  amd  Fabrycky  (2011)  (left). 


The  processes  described  in  Figure  5  can  be  summarized  in  five  steps:  problem 
definition,  mission  analysis,  functional  analysis,  performance  requirements,  and 
requirements  trade-off.  This  process  is  central  to  the  research  in  this  thesis.  Further 
exploration  of  the  steps  can  clarify  the  process. 

(1)  Problem  Definition 

Problem  definition,  or  what  Blanchard  and  Fabrycky  (2011)  call  “Problem 
definition  and  identification  of  need”  (74)  and  SMC  (2005)  calls  “Customer  needs  and 
other  process  inputs,”  (46)  describes  the  purpose  behind  developing  the  system.  Raw 
customer  inputs,  sometimes  called  primitive  needs  statements,  are  analyzed  to  determine 
what  the  actual  problem  is  and  why  the  problem  exists.  This  is  the  starting  point  for 
developing  requirements. 
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(2)  Mission  Analysis 

Mission  analysis,  what  Blanchard  and  Fabrycky  call  “Operational  requirements” 
and  “Maintenance  and  support  concepts”  and  SMC  calls  “Mission  and  Environmental 
Analysis”  in  essence,  describes  what  the  system  needs  to  do  and  the  context  within  which 
it  will  operate.  This  step  should  lay  out  the  concept  of  operations  for  the  system, 
including  scenarios  and  vignettes  describing  how  it  is  used,  for  what,  by  whom,  where 
and  why. 

(3)  Functional  Analysis 

Functional  analysis  is  somewhat  similar  in  that  both  the  Blanchard  and  Fabrycky 
text  and  SMC  handbook  refer  to  this  as  “Functional  analysis  and  allocation,”  but  SMC 
adds  another  step:  “Functional  Requirements  Identification.”  The  Functional  analysis 
decomposes  the  system  into  functions  that  it  will  be  required  to  do  to  address  the 
problem,  as  stated  during  Problem  Definition,  while  doing  the  mission  or  tasks  described 
in  the  mission  analysis. 

(4)  Performance  Requirements 

In  this  step,  called  “Technical  performance  measures”  and  “Performance 
Requirements  and  Design  Constraints  Definitions/Refinement”  by  Blanchard  and 
Fabrycky  and  SMC  respectively,  additional  requirements  are  added  that  describe  how 
well  the  system  must  perform  the  functions  described  in  the  functional  analysis.  In 
addition  to  describing  the  functions,  additional  requirements  may  be  added  in  this  step 
that  describe  how  well,  in  terms  of  quantifiable  measures,  the  system  must  perform  in  its 
mission. 

(5)  Requirements  Trade-off 

Blanchard  and  Fabrycky  call  this  “System  trade-off  analysis”  while  the  SMC  puts 
it  in  a  “Requirements  Foop.”  This  step  is  often  overlooked  in  system  development  to  the 
detriment  of  the  customer  procuring  the  system.  One  GAO  report  on  the  Defense 
Acquisition  Process  expresses  concerns  from  the  service  chiefs  and  other  senior  leaders 
that  there  is  a  lack  of  a  systems  engineering  approach  to  requirements,  specifically  aimed 
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at  what  technology  and  resources  are  available  for  a  system  (GAO  2015).  A  careful 
analysis  needs  to  look  at  the  resources  that  the  customer  has  and  the  technology  that  is 
available  and  adjust  the  requirements  of  the  system  to  ensure  success  in  development. 

Blanchard  and  Fabrycky  present  a  generally  well-accepted  process  that  focuses  on 
physical  systems,  but  can  also  be  applied  to  software  systems.  It  is  common  for 
organizations  to  adapt  the  systems  engineering  process  to  their  purposes.  For  example, 
the  SMC  systems  engineering  handbook  describes  the  requirements  generation  process 
based  on  its  own  processes  and  procedures;  however,  it  generally  follows  that  of 
Blanchard  and  Fabrycky. 

Regarding  software  systems  specifically,  Rajat  Sud  (2003),  in  his  thesis  on 
software  requirements  generation,  calls  the  process  “requirements  engineering”  and 
though  the  language  is  slightly  different,  the  purpose  and  mechanisms  are  generally  the 
same.  Sud,  as  described,  and  others  such  as  Sidky  (2002),  explain  that  there  are  other 
tools  and  processes  in  problem  definition  that  can  be  used  to  explore  more  fully  the 
problem  space.  These  tools  such  as  fishbone  diagrams  or  cause-effect  diagrams  help 
designers  get  to  the  root  of  what  the  customer  views  as  their  problem  (Sidky  et  al.  2002). 

When  it  comes  to  the  nature  of  requirements,  Major  General  Greene  (2003),  a 
former  Deputy  for  Acquisition  and  Systems  Management  (DASM),  described  that  when  a 
system  is  part  of  a  system  of  systems,  it  is  critical  that  requirements  are  developed  from 
the  top  down  to  encourage  an  integrated  view  throughout  development.  With  respect  to 
program  success  and  the  importance  of  proper  requirements,  one  GAO  report  indicates 
several  senior  leaders  expressed  concern  that  “systems  engineering  capabilities  are 
generally  lacking  in  the  requirements  development  process,”  and  that  that  leads  to 
requirements  creep,  cost  over-runs,  and  schedule  slip  (GAO  2015). 

The  report  states  that  total  system  costs  are  typically  not  realized  until  after  a 
systems  engineering  analysis  is  conducted.  Prior  to  that,  the  high-level  requirements  only 
provide  limited  visibility  into  how  the  system  will  function  and  what  the  real  cost  and 
schedule  will  be.  The  GAO  report  also  states  “It  is  often  at  this  point  (after  a  systems 
engineering  analysis)-when  the  technical  specifications  are  finally  understood  and  the 
design  challenges  are  recognized — that  cost  and  schedule  increases  materialize  in  a 
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program”  (14).  So,  it  is  important  to  have  that  work  done  prior  to  committing  to  a  budget 
and\  or  timeline  for  development. 

In  the  case  of  LAWST,  the  documents  that  are  examined  in  this  literature  review 
have  a  few  purposes.  First,  the  thesis  examines  the  artifacts  describing  the  development 
of  LAWST  and  attempt  to  fit  the  development  into  an  existing  requirements  generation 
model.  Next,  the  processes  that  are  presented  in  this  literature  will  provide  the  framework 
for  the  methodology  used  to  develop  system  requirements  from  a  systems  engineering 
standpoint.  Both  problem  definition  and  a  top-down  approach  are  vital  for  creating 
requirements  that  are  more  integrated  and  complete. 

B.  APPLICATION 

This  chapter  presents  a  number  of  different  aspects  of  requirements.  It  articulates 
the  importance  of  generating  correct  requirements  using  a  systematic  approach.  It 
outlines  the  type  of  process  that  can  be  used  to  develop  requirements.  It  also  looks  at  the 
repercussions  for  not  using  a  systems  engineering  approach  prior  to  development.  This 
information  is  the  basis  to  support  the  methodology  used  for  this  study  as  articulated  in 
Chapter  III. 
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III.  METHODOLOGY 


A.  OVERALL  STRATEGY  FOR  ADDRESSING  RESEARCH  QUESTIONS 

Our  research  begins  with  determining,  from  E20,  how  the  requirements  for 
LAWST  were  derived  and  developed.  The  second  and  parallel  effort  will  be  determining 
the  system  requirements  based  on  an  engineering  approach.  We  will  make  a  comparison 
between  the  two  requirements  sets  to  identify  the  differences  and  determine  as  to  why 
those  differences  exist. 

LAWST  will  undergo  an  abbreviated  systems  analysis  with  the  requirements 
generated  from  the  systems  engineering  process  and  those  requirements  that  were 
originally  used  to  develop  LAWST.  This  is  in  slight  contrast  to  previous  analysis  where 
an  attempt  was  made  to  derive  system  requirements  from  the  actual  performance  of 
LAWST  (Hall  2016).  Normally,  the  goal  of  systems  analysis  is  to  determine  the  best 
system  among  a  number  of  similar  systems.  In  this  case,  the  research  will  only  evaluate 
LAWST  capabilities  against  the  system  requirements  to  determine  whether,  and  to  what 
extent,  LAWST  meets  the  original  requirements,  as  well  as  how  it  meets  requirements 
developed  using  the  systems  engineering  approach.  We  also  identify  any  lost  utility  that 
was  either  not  developed  or  not  designed  in  LAWST. 

The  research  quantifies  the  differences  in  the  development  of  the  two  sets  of 
requirements.  The  problem  definition,  the  purpose  for  which  LAWST  was  developed,  is 
used  in  developing  a  set  of  system  requirements  that  describe  a  system  that  will  address 
that  problem.  Ultimately  this  problem  definition  is  the  basis  for  the  system. 

Determining  what  the  requirements  generation  process  was  for  the  current  version 
of  LAWST  is  a  straight-forward  gathering  of  artifacts  that  led  to  the  development  of  the 
tool.  There  should  be  relatively  little  synthesis  of  information  to  articulate  what  the 
process  was,  as  this  step  is  more  of  an  investigation.  The  systems  engineering  approach  to 
requirements  generation  will  follow  the  process  that  was  briefly  described  in  Chapter  II 
of  this  thesis.  That  is:  problem  definition,  mission  analysis,  functional  analysis, 
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performance  requirements,  and  requirements  trade-off.  Finally,  a  framework  will  be 
presented  for  E20  to  follow  in  developing  requirements  for  future  systems. 

B.  DETERMINE  ORIGINAL  REQUIREMENTS 

There  are  a  number  of  documents  that  are  available  that  indicate  the  original 
method  for  requirements  generation.  The  original  intent  behind  the  requirements  that 
were  used  to  develop  LAWST  must  be  considered  to  understand  the  context  in  which  the 
requirements  were  generated.  The  research  should  show  the  detailed  process  used  in  the 
original  requirements  generation  process  and  be  supported  by  artifacts  leading  up  to  the 
development. 

C.  REQUIREMENTS  GENERATION 

1.  Problem  Definition 

The  starting  point  for  the  systems  engineering  process  is  defining  the  customer’s 
problem.  It  may  seem  like  an  easy  prospect  to  ask  the  customer  what  the  problem  is; 
however,  the  customer  in  many  cases  may  not  be  able  to  articulate  the  problem  clearly.  It 
is  often  the  case  that  customers  begin  to  solve  their  problem  by  looking  for  a  solution  that 
may  only  partially  address  what  they  want  to  solve.  They  may  also  start  by  offering  a 
solution  before  defining  the  problem.  In  those  cases,  customers  approach  an  engineer  to 
build  a  solution  that  they  think  they  (the  customers)  want.  This  usually  leads  to  wasted 
resources  because  the  solution  the  customers  wanted  does  necessarily  not  solve  their 
problem.  It  follows  that  novice  designers  usually  give  the  customer  what  they  ask  for 
rather  than  identifying,  then  delivering  what  the  customer  actually  desires  (Cross  2011). 
Designers  spend  a  significant  amount  of  time  thinking  about  a  problem,  framing  it  in 
different  ways,  and  trying  to  fully  understand  it.  Without  spending  an  appropriate  effort 
on  analyzing  and  understanding  the  problem,  any  solution  may  be  inappropriate  or 
incomplete. 

This  research  will  begin  with  the  primary  customer  for  LAWST.  The  Marine 
Corps  Expeditionary  Energy  Office  was  responsible  for  the  development,  through  Group 
W,  of  the  current  version  of  LAWST.  The  primary  mission  of  E20,  based  on  its  website 
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(http://www.hqmc.marines.mil/e2o/Mission-Vision)  ,  is  to  improve  the  effectiveness  of 
the  Marine  Corps  by  investing  in  ways  to  improve  the  energy  consumption  of  combat 
systems  and  efficiency  of  the  support  structure  on  which  Marine  expeditionary  forces 
rely. 

Since  E20  is  part  of  the  Marine  Corps  and  its  mission  and  outcomes  are  nested 
within  those  of  the  Marine  Corps,  other  sources  that  will  help  define  the  problem  include 
future  operational  concepts  for  the  Marine  Corps,  regulations  and  field  manuals  related  to 
planning  and  wargames,  and  instructions  and  orders  related  to  modeling  and  simulation. 

2.  Mission  Analysis 

The  Analysis  of  a  system’s  mission  explores  the  context  of  the  system.  The 
system  will  be  used  for  some  task  that  needs  to  be  thoroughly  explored.  Questions  that 
need  to  be  answered  here  include: 

Who  performs  the  task? 

Who  else  is  involved  in  the  task? 

Why  is  the  task  being  done? 

Where  will  the  system  be  used? 

What  other  systems  will  this  one  interact  with? 

The  comments  from  the  stakeholder  and  documents  that  are  explored  as  part  of 
the  problem  definition  are  helpful  in  identifying  the  right  questions  to  ask  and  point  in  the 
right  direction  for  the  answers. 

Considering  the  models  for  requirements  generation  from  Chapter  II,  it  is 
important  to  note  the  process  is  rarely  sequential;  in  the  course  of  researching  the 
problem  context,  it  might  become  necessary  to  revisit  and  revise  the  problem  statement. 
In  turn,  revising  the  problem  statement  may  also  refocus  the  mission  of  the  system  and 
the  tasks  it  must  perform  or  enable. 

Some  products  from  this  phase  may  include  a  concept  of  operations  (CONOP) 
statement  and/or  operational  view  diagram  that  defines  how  the  system  will  be  used.  It  is 
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also  helpful  to  provide  some  link  from  the  CONOP  to  the  questions  and  answers  in  the 
mission  analysis  back  to  the  problem  statement.  Diagram  that  shows  the  decomposition 
of  the  problem  based  on  the  mission  context  using  a  dendritic  tool,  like  a  fishbone 
diagram  that  shows  the  decomposition  in  some  logical  way  can  be  helpful.  These  types  of 
diagrams  help  provide  the  required  traceability  when  the  system  requirements  begin  to 
emerge. 


3.  Functional  Analysis 

Functional  analysis  begins  to  add  a  layer  of  actions  that  the  system  must  do  to 
operate  in  a  way  that  is  consistent  with  the  CONOP  from  the  mission  analysis.  There  are 
several  tools  that  will  be  used  in  this  analysis.  Scenarios  describe  a  system  in  action  as  it 
executes  task  that  it  was  designed  to  do.  Vignettes  are  short,  detailed  narratives  that 
describe  specific  actions  or  sets  of  actions  that  the  system  completes  in  the  scenario. 
Engineers  can  describe  the  vignettes  in  diagrams  like  a  functional  flow  block  diagram. 
Once  all  of  the  tasks  that  a  system  needs  to  perform  in  the  scenario  are  described 
functionally,  engineers  organize  like  functions  into  groupings  that  begin  to  form  a 
hierarchy  that  forms  the  functional  decomposition  of  the  system. 

A  scenario  provides  additional  context  to  the  system  that  may  not  be  apparent  in 
the  previous  set  of  documents  that  are  created  as  part  of  the  mission  analysis.  The 
scenario  provides  information  on  the  environment  and  begins  to  address  the  time  scale  in 
which  that  task  must  be  performed.  It  also  articulates  interactions  between  operators  and 
the  system,  the  system  and  other  systems  and  brings  out  information  requirements  that 
are  transferred  between  each.  Vignettes  can  not  only  fit  into  the  overall  scenario  but  also 
offer  additional  detail  on  critical  tasks  that  the  system  must  accomplish. 

Functional  flow  block  diagrams  (FFBDs)  are  a  pictorial  method  of  showing  a 
scenario.  They  depict  each  element  participating  in  the  scenario  and  show  the  tasks  that 
each  of  those  elements  performs.  Additionally,  they  show  the  interactions  between  the 
operational  elements,  specify  which  tasks  are  dependent  on  others  and  the  order  of 
executing  task,  and  estimate  how  long  the  tasks  should  take. 
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Once  the  scenario  and  vignettes  have  been  mapped  out  in  a  FFBD,  engineers 
capture  the  functions  that  the  system  performs,  along  with  any  inputs,  outputs,  control 
mechanisms,  and  resource  requirements. 

4.  Performance  Requirements 

Requirements  for  a  system  do  not  need  to  be  captured  only  after  functional 
analysis  of  the  system.  At  each  step  in  the  process,  requirements  begin  to  emerge.  In  the 
problem  definition  phase,  requirements  may  appear  in  regulatory  or  statutory  documents. 
The  mission  analysis  may  articulate  environmental  constraints  in  which  the  system  must 
operate  or  times  when  the  system  will  or  will  not  be  operational.  These  are  all  valid 
requirements.  There  is  no  agreed  upon  time  or  place  in  the  process  where  requirements 
should  be  developed,  but  going  through  the  process  completely  ensures  the  greatest 
exposure  to  potential  requirements  for  the  system. 

In  relation  to  the  functional  analysis,  every  function  can  be  mapped  to  a 
requirement,  even  if  the  requirement  has  a  binary  measure.  In  many  cases,  the  additional 
information  such  as  inputs  and  outputs,  control  mechanisms,  resource  requirements  and 
timing  will  have  more  substantive  requirements  that  can  be  measured  in  a  quantitative 
way.  There  is  a  risk  that  more  qualitative  requirements  may  be  interpreted  in  different 
ways  causing  confusion  and  conflict  in  later  stages  of  development.  Therefore,  while  it  is 
not  always  possible  to  avoid  them,  it  is  advisable  to  make  the  effort  to  qualify  the 
requirements  with  additional  descriptions. 

Since  LAWST  is  specifically  designed  to  support  logisticians  in  wargames,  this 
section  shows  the  specific  linkages  of  the  requirements  back  to  the  FFBDs,  and  in  turn 
the  scenarios  that  describe  a  wargame.  The  requirements  also  provide  information  on 
timing  and  interactions  that  the  system  has  as  the  logistician  moves  through  the  planning 
and  wargame  process. 

5.  Requirements  Trade-off 

The  requirements  trade-off  phase  is  the  point  in  the  systems  engineering  process 
when  it  begins  to  transition  to  more  tangible,  solution-oriented  tasks  for  engineers.  At  this 
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point,  physical  components,  blocks  of  code,  schemes  for  training  operators,  adjustments 
to  doctrine,  and  other  Doctrine,  Organization,  Training,  Materiel,  Leadership/Education, 
Personnel,  Facilities  and  Policy  (DOTMLPF)  considerations  are  fit  together  in  different 
ways  to  explore  the  best  combination  of  factors  that  meet  the  stakeholder’s  needs.  The 
measures  of  effectiveness  (MOEs)  and  measures  of  performance  (MOPs)  that  are  used  to 
evaluate  the  different  alternatives  should  reflect  the  priorities  and  interests  of  the 
stakeholder.  While  the  MOEs  and  MOPs  can  be  developed  by  the  engineer,  they  should 
be  well  understood  and  accepted  by  the  stakeholders  before  any  comparison  of 
alternatives  is  done. 

This  type  of  analysis  is  often  called  systems  analysis  (SA)  and  is  often  conducted 
by  analysts  who  specialize  in  that  discipline.  Often  a  report  is  developed  to  inform  a 
decision  maker  of  the  various  feasible  alternatives  and  explain  which  ones  best  address 
the  problem  for  which  the  system  is  being  developed. 

In  the  case  of  this  research,  LAWST,  as  the  materiel  solution,  will  be  the  only 
alternative  that  is  evaluated.  Additionally,  this  research  will  not  take  other  DOTMLPF 
considerations  into  account  and  MOPs  will  be  those  that  are  described  in  the  systems 
requirements  developed  up  through  the  performance  requirements  phase.  For  each 
requirement,  LAWST  will  be  evaluated  on  whether  it  meets  the  requirement  and  to  what 
extent. 

D.  COMPARISON  OF  REQUIREMENTS 

It  is  important  to  determine  the  difference  between  the  requirement  sets  developed 
with  and  without  a  systems  engineering  process.  This  step  should  be  focused  on  the 
requirements  from  one  set  or  the  other  that  do  not  match  or  address,  in  any  way,  a 
requirement  from  the  other  set.  This  allows  insight  into  the  potential  shortfalls  or 
oversights  in  current  requirements  generation  processes.  On  the  other  hand,  there  may  be 
evidence  that  there  are  other  factors  that  were  not  captured  by  a  systems  engineering 
process  that  may  be  important  to  the  customer. 
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1.  LAWST  Compared  to  Original  Requirements 

A  majority  of  the  work  for  this  step  has  been  completed  by  Dr.  Steven  Hall  in 
2016  as  part  of  an  assessment  of  the  readiness  of  LAWST  to  undergo  a  VV&A.  That 
information  will  be  reviewed  during  this  step  of  the  methodology. 

2.  LAWST  Compared  to  SE  Developed  Requirements 

This  portion  of  the  methodology  will  assess  LAWST  against  each  of  the 
requirements  developed  during  the  requirements  generation  process  using  a  systems 
engineering  approach.  Each  requirement  will  have  an  explanation  of  how  LAWST  does 
or  does  not  fulfill  that  requirement.  LAWST  will  demonstrate  the  function  described  in 
the  requirement  or  it  will  not.  If  LAWST  does  perform  the  required  function,  it  should 
explain  to  what  extent  it  fulfills  the  requirement.  For  any  requirement  in  which  it  is  not 
readily  apparent  that  LAWST  addresses  it,  there  should  be  some  method  by  which  the 
requirement  can  be  tested  or  determined. 

E.  QUANTIFY  DIFFERENT  APPROACHES 

There  is  a  resource  cost  associated  with  every  aspect  of  system  development.  The 
differences  in  the  approaches  used  to  develop  LAWST  will  be  quantified  to  evaluate 
those  costs.  For  the  purposes  of  this  research,  the  percent  difference  between  the 
requirements  sets  may  be  used  to  make  an  estimate  of  the  additional  cost,  if  one  exists, 
required  to  incorporate  the  additional  requirements.  A  work  breakdown  structure,  which 
useful  in  determining  system  costs,  is  also  used  in  the  analysis. 

F.  DEVELOP  FRAMEWORK  FOR  FUTURE  DEVELOPMENT 

As  a  final  element  in  this  methodology,  summarize  the  process  used  to  generate 
requirements  using  the  systems  engineering  process.  This  framework  can  be  used  with 
any  generic  system  or  software.  This  framework  will  provide  a  way  for  future  systems  to 
be  developed  with  the  most  complete  set  of  requirements  to  reduce  future  costs  and 
development  time  in  making  changes  to  the  first  iteration  of  the  system. 
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This  methodology  will  allow  the  research  to  answer  the  primary  research 
questions.  It  will  determine  how  the  original  requirements  for  LAWST  were  developed, 
what  the  requirements  for  the  system  would  be  (had  a  systems  engineering  approach  been 
used),  and  then  determine  if  LAWST  meets  those  requirements  using  an  SE  approach. 
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IV.  COMPARATIVE  ANALYSIS  OF  REQUIREMENTS 
GENERATION  PROCESSES 


A.  PRESUMED  ORIGINAL  LAWST  REQUIREMENTS 

The  assessment  of  LAWST’s  readiness  to  undergo  a  V&V  process  reveals  that  the 
requirements  were  neither  included  in  the  documentation  describing  the  system,  nor  was 
there  evidence  of  the  process  used  to  generate  the  requirements  for  the  current  version  of 
LAWST  (Hall  2016).  However,  in  separate  documents  information  on  the  “Expeditionary 
Force  21  (EF-21)  Energy  Study  and  Wargame,”  which  was  conducted  in  early  2015  to 
examine  the  ability  of  the  Marine  Corps  to  support  operations  from  an  energy 
perspective,  shows  a  modeling  effort  to  determine  if  the  anticipated  fuel  supply  meets  the 
demand  of  the  units.  The  wargame  document  includes  notes  from  the  E20  director  that 
indicate  priorities  for  the  effort  (E20,  unpublished  document).  A  diagram  from  the 
document  shown  in  Figure  6  indicates  the  origin  of  LAWST. 


Study 


Study 


Initial  Concept 


A 


Modify  MPEM 


A 


Wargame 


Directed  Modelling  Effort  : 
Expeditionary  Energy  Supply 


Refined  Model 


l 


Figure  6.  EF-21  Energy  Study  and  Wargame  Concept.  Source:  EF-21  Energy 

Study  and  Wargame  document  (E20,  unpublished  document) 


The  block  labeled  “Directed  Modelling  Effort:  Expeditionary  Energy  Supply,”  in 
Figure  6  is  what  eventually  becomes  LAWST.  Documentation  that  is  provided  with 
LAWST  indicates  that  the  Marine  Air-Ground  Task  Force  (MAGTF)  Power  and  Energy 
Model  (MPEM)  is  a  basis  for  the  demand  and  LAWST  fills  in  the  gaps  with  respect  to 
the  demand  created  by  the  logistics  network  itself.  In  addition,  the  document  contains  a 
set  of  questions  found  in  Table  1. 
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Table  1.  Study  Questions  from  the  EF-21  Energy  Study  and  Wargame. 
Source:  EF-21  Energy  Study  and  Wargame  document  (E20, 
unpublished  document). 


1 

What  do  the  supply  and  demand  curves  look  like  from  Sea-Echelon  Area 
(SEA)  to  the  FLOT? 

2 

Where  are  the  CVs  in  the  energy  system? 

3 

How  much  fuel  is  required  by  type  in  each  of  the  five  zones?  What  is  the 
capability  to  support  in  each  zone?  What  are  the  risks  by  zone? 

4 

What  is  the  demand  of  the  various  fuel  types  at  various  points  in  the 
operation? 

5 

What  are  the  capacities  to  deliver  and  store  fuel  in  each  zone?  Do  they 
meet  requirements? 

6 

What  kind  of  USN/USMC  C2  arrangements  are  necessary  to  assure  fuel 
supplies? 

7 

How  much  fuel  does  it  cost  to  deliver  fuel  at  various  points  on  the 
battlefield  and  as  you  alter  battlefield  conditions? 

The  questions  posed  in  the  study  and  wargame  concept  are  found  in  a  later 
presentation  in  which  they  are  mapped  to  a  set  of  proposed  requirements.  Those 
requirements  are  listed  in  Table  2. 


Table  2.  List  of  Requirements  from  the  EF-21  Energy  Study  and  Wargame 
Support  Proposals.  Source:  Group  W  (unpublished  document). 


The  solution  must: _ 

Calculate  supply/demand  by  zone,  echelon,  or  level _ 

Define  throughput,  storage,  and  delivery  capability  at  each  node  or  arc _ 

Calculate  fuel  consumed  to  deliver  fuel _ 

Accommodate  (two)  fuel  types  and  multiple  types  of  delivery  assets _ 

Accommodate  other  classes  of  supply _ 

5.1  Compete  for  delivery  assets _ 

5.2  Deliver  of  other  classes  of  supply  consumes  fuel _ 

Account  for  geographic  separation  of  units/assets _ 

Allow  for  dynamic  changes  to  the  network  (i.e.,  new  nodes  to  support  advancing  forces, 
units  changing  location/fuel-resupply  points,  etc.) _ 


The  presentation  goes  further  and  links  the  proposed  requirements  to  the  study 
question  in  Figure  7. 
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Requirements  map  to  study  questions 


\ 

•  Does  supply  meetdemand? 

>  R1.  R2.  R3.  R4.  R5.1.R5.2 

•  What  does  the  supply  and  demand  curves  look  like  from  SEA  to  the  FLOT? 

>  R1.R4 

•  Where  are  the  CVs  in  the  energy  system?* 

>  R1.R2.R4.  R5.1.R.  6 

•  How  much  fuel  is  required  by  type  in  each  of  the  5  zones?  What  is  the 
capability  to  support  each  zone?  What  are  the  risks  in  each  zone?* 

>  R1 .  R2,  R3 

•  What  is  the  stress  against  the  various  fuel  types  at  various  points  in  the 
operation? 

>  R1.R4.R7 

•  What  are  the  capacities  to  deliver  and  store  fuel  in  each  zone?  Do  they  meet 
requirements? 

>  R2.  R5  1 

•  What  kind  of  USN/USMC  C2  arrangements  are  necessary  to  assure  fuel 
supplies?* 

•  How  much  fuel  does  it  cost  to  deliver  fuel  at  various  points  on  the  battlefield 
and  as  you  alter  battlefield  conditions? 

>  R3.  R6.  R7 

J  5 


Figure  7.  Linkage  of  Proposed  Requirements  to  Study  Questions.  Source:  EF- 
21  Energy  Study  and  Wargame  Support  Proposals  (Group  W, 
unpublished  document). 


This  indicates  that  the  system  requirements  that  led  to  the  development  of 
LAWST  originated  primarily  to  support  EF-21  Energy  Study  and  Operational  Reach 
Wargame.  There  is  no  description  of  the  process  used  to  decompose  the  study  questions 
into  any  functions  that  a  system  must  perform  during  its  operation  that  provides  the  logic 
used  to  develop  the  requirements  that  the  developer  suggests. 

Additional  information  in  the  support  proposal  presentation  indicates  an  initial 
feasibility  analysis  had  different  potential  solutions  (STORM  Lite,  Excel,  ExtendSim, 
and  Instantaneous  Supply  Calculator)  (Group  W,  unpublished  document).  All  were 
evaluated  against  the  requirements  to  evaluate  suitability  and  cost.  The  results  of  the 
analysis  were  not  apparent  in  the  presentation  and  there  are  no  additional  documents  that 
indicate  the  further  analysis  exists. 
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B.  REQUIREMENTS  GENERATION  FOR  LAWST  USING  A  SYSTEMS 

ENGINEERING  APPROACH 

1.  LAWST  Problem  Definition 

The  problem  definition  is  a  mechanism  by  which  the  purpose  for  a  system  is 
established  in  order  to  begin  the  systems  engineering  process. 

E20  is  the  primary  and  priority  stakeholder  or  customer  for  LAWST.  E20 
indicated  that  it  would  like  LAWST  to  be  distributed  as  an  aid  in  planning  and 
wargaming  at  the  tactical  level.  Since  wargaming  is  an  integral  part  of  planning  and 
evaluating  courses  of  action  (COAs),  wargaming  is  always  assumed  part  of  the  planning 
process.  The  E20  director,  at  the  time  of  the  development,  also  made  hand-written 
comments  on  the  EF-21  Energy  Study  and  Operational  Reach  Wargame  documents, 
which  serve  as  an  indication  for  the  priorities  of  development.  Group  W  points  out  an 
important  element,  with  respect  to  tactical  units,  that  logistics  assets  are  shared  among  all 
classes  of  supply  and  any  tool  that  is  developed  needs  to  include  all  of  those  classes. 
Additional  comments  add  to  the  context  of  the  problem:  The  Vision  Statement  says 
“efficient  use  of  vital  resources”  (E20  2017,  1)  and  the  Intent  Statement  further  clarifies 
that  the  system  should:  “to  change  the  way  the  Marine  Corps  employs  energy  and 
resources.”  (E20  2017,  1).  These  statements  and  pieces  of  information  went  into  crafting 
the  problem  definition:  The  U.S.  Marine  Corps  does  not  have  a  robust  tool  to  plan, 
analyze,  and  optimize  logistics  networks  in  support  of  Combined,  Joint,  and  Interagency 
operations  in  a  non-contiguous  JOA  against  a  range  of  non-hostile  to  hostile  threats. 

2.  System  Mission  Analysis 

The  mission  analysis  is  a  critical  step  in  the  exploring  the  context  of  the  problem. 
This  system  mission  analysis  is  different  from  the  mission  analysis,  or  problem  framing, 
that  is  described  in  later  paragraphs.  The  system  mission  analysis,  that  is  the  focus  of  this 
section,  is  analyzing  the  mission  and  tasks  that  LAWST  would  perform  as  part  of  its 
operations  in  the  environment  in  which  it  will  operate. 

The  Marine  Corps  Planning  Process  (MCPP)  is  articulated  in  MCWP  5-1  (US 
Marine  Corps  2010).  There  are  six  basic  steps  in  the  process:  Problem  Framing,  Course 
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of  Action  (COA)  Development,  COA  Wargaming,  COA  Comparison  and  Decision, 
Orders  Development,  and  Transition.  Problem  Framing  is  a  methodical  analysis  of  a 
given  mission;  the  specified  and  implied  tasks  that  a  unit  must  do,  limitations, 
information  requirements  and  other  considerations  that  planners  need  to  take  into  account 
when  developing  their  own  plans  to  accomplish  their  given  mission.  During  COA 
development,  the  planning  staff  develops  a  number  of  distinct  courses  of  action  to 
address  the  given  mission.  COA  Wargaming  refers  to  evaluating  each  COA  based  on 
enemy  action,  branches  and  sequels  at  decision  points  and  potential  shortcomings.  After 
each  COA  is  evaluated,  the  staff  weights  each  COA  based  on  evaluation  criteria 
developed  prior  to  the  wargame  and  based  on  the  score  of  each  COA,  recommends  a 
course  of  action  to  the  commander  during  the  COA  Comparison  and  Decision.  This  step 
is  followed  by  Orders  development  that  entails  the  production  of  the  orders  for 
subordinate  units.  Orders  include  a  detailed  description  of  the  course  of  action, 
coordinating  instructions,  logistics  instructions,  and  command  and  control  instructions. 
Transition  generally  goes  through  the  dissemination  of  orders,  back  briefs,  rehearsals,  and 
other  pre-mission  tasks.  This  is  a  concise  view  of  the  planning  process  but  provides  an 
overview  for  reference. 

In  the  Problem  Framing,  there  are  a  number  of  important  pieces  of  information 
that  a  logistician  must  gather  in  preparation  for  the  course  of  action  development.  The 
location  of  the  mission  is  a  critical  starting  point  for  gaining  additional  information  about 
the  situation.  The  logistician  can  determine  existing  infrastructure  that  could  be  used  to 
support  forward  elements,  initial  estimates  of  throughput  for  major  supply  routes,  initial 
distances  and  time  required  from  sea  bases,  location  of  major  logistics  nodes,  and  current 
disposition  of  units  and  supplies. 

During  the  COA  development  phase  the  operations  officer  usually  develops  the 
scheme  of  maneuver  for  a  specific  COA  and  the  logistician  develops  a  complimentary 
logistics  concept  in  support  of  that  COA.  The  logistics  concept  should  be  as  detailed  as 
possible  to  support  the  COA  Wargaming,  Comparison  and  Decision. 

During  the  COA  Wargaming,  the  logistician  may  be  asked  to  provide  his  or  her 

evaluation  of  a  specific  aspect  of  a  COA  with  respect  to  the  logistics  concept,  immediate 
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feedback  is  preferred  based  on  short  timelines  for  planning  so,  any  information  that 
logistician  has  needs  to  be  readily  accessible  and  interpreted.  Information,  as  articulated 
in  MCWP  5-1  should  be  granular  to  two  levels  down  (i.e.,  if  this  is  a  battalion  level  plan, 
wargaming  is  typically  conducted  down  to  the  platoon  level).  In  addition,  the  logistician 
must  be  able  to  adapt  to  the  wargaming  method  that  the  facilitator  (usually  the  operations 
officer  or  executive  officer)  chooses:  belt,  avenue  in  depth,  critical  task  or  box  method. 
The  belt  method  refers  to  wargaming  a  COA  within  a  specific  set  of  times  or  phase  lines. 
The  avenue  in  depth  method  allows  the  facilitator  to  wargame  a  specific  unit  or  task  over 
the  entire  duration  of  an  operation.  The  critical  task  or  box  method  refers  to  examining 
specific  times  or  places  within  each  COA  (US  Marine  Corps  2010). 

In  the  COA  Comparison  and  Decision,  the  logistician  needs  to  articulate  the 
feasibility,  strengths,  and  weaknesses  of  each  COA  with  respect  to  the  logistics  concept. 
When  evaluating  a  system,  based  on  the  tasks  it  needs  to  complete,  the  analysis  should 
include  an  indication  of  how  well  the  system  should  do  any  specific  task.  In  the  case  of 
the  MCPP,  the  best  measures  are  based  on  extreme  cases.  For  instance,  the  Rapid 
Response  Planning  Process  dictates  six  hours  to  complete  the  planning  process,  allocating 
90  minutes  total  to  complete  Problem  Framing,  COA  Development,  COA  Wargaming, 
and  COA  Comparison  and  Decision.  This  timing  information  is  critical  in  articulating 
requirements  that  can  support  the  MCPP. 

Systems  Engineers  use  scenarios  and  vignettes  in  the  mission  analysis  phase.  The 
scenario  is  an  overarching  narrative  that  describes  how  the  system  will  be  used.  In  this 
case,  the  scenario  is  the  MCPP.  Vignettes  describe,  in  more  detail,  specific  tasks  within 
the  scenario.  Two  vignettes  that  are  helpful  in  this  case  are  the  Problem  Framing  and  the 
COA  Wargaming  that  offer  vital  information  on  the  type  of  tasks  that  a  system  must 
support. 

Designers  sometimes  use  a  mind-map  to  link  the  different  aspects  of  the  mission 
analysis  for  a  better  understanding  of  the  logistics  tasks  as  part  of  the  MCPP.  Mind¬ 
mapping  allows  designers  to  expand  on  topics,  examine  linkages  between  items,  and 
group  ideas  together  to  organize  their  work.  Figure  8  was  created  in  an  application  hosted 
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on  mindmapmaker.org  called  “Mindmaps”  and  shows  one  specific  branch  of  a  mind-map 
related  to  wargaming  a  COA. 


Figure  8.  Mind-map  Related  to  Conducting  Wargame  on  a  COA. 


This  portion  of  the  mind-map  examines  COA  wargaming.  It  organizes  the 
methods  of  wargaming  and  the  different  considerations  that  need  to  be  taken  into  account 
when  a  wargame  is  conducted.  For  instance,  Figure  8  shows  the  wargame  and  branches 
describing  different  aspects  and  considerations  of  a  wargame:  the  method,  the  enemy, 
evaluating  two  levels  down,  action-reaction-counteraction.  This  type  of  tool  allows  a 
large  number  of  related  or  unrelated  tasks  to  be  quickly  captured  and  organized  for  better 
visualization  of  the  tasks  involved  with  this  system.  A  full  mind-map  for  this  mission 
analysis  can  be  found  in  Appendix  A. 

This  mission  analysis  provides  a  structure  leading  into  the  functional  analysis.  It 
provides  some  top-level  functions  that  the  system  must  do  in  performing  the  tasks  during 
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the  mission  and  provides  additional  detail  to  an  otherwise  arbitrary  selection  of  functions 
that  the  system  will  perform. 

3.  Functional  Analysis 

The  functional  analysis  step  in  the  SE  process  is  really  the  beginning  of  looking  at 
the  system  that  will  address  the  problem  defined  in  the  problem  definition,  but  within  the 
context  of  the  tasks  outlined  in  the  mission  analysis.  The  system,  at  this  point,  should  be 
defined  by  the  functions  that  it  needs  to  do.  Those  functions  should  complement  and 
assist  the  planners,  from  the  scenarios  in  the  mission  analysis  step,  in  accomplishing  the 
tasks  that  are  described  in  the  scenarios. 

At  a  top-level  view,  the  system  can  be  bounded  by  the  tasks  that  describe  its  use. 
In  this  case,  logisticians  need  to  begin  analysis  by  creating  concepts  or  plans  to  support 
COAs  developed  during  the  COA  development  phase  of  the  MCPP.  Once  an  analysis  of 
the  COAs  is  complete,  the  system  has  completed  its  tasks.  The  comparison  and  decision 
of  which  COA  to  use  is  based  on  criteria  that  the  logistician  may  not  have  any  control 
over;  however,  the  commander  deciding  which  COA  to  execute  will  take  the  logistician’s 
recommendations  into  consideration  when  making  the  decision.  Figure  9  shows  the  high- 
level  functional  decomposition  of  a  system  that  supports  a  logistician  in  analyzing  a 
COA. 


Figure  9.  Top  Fevel  Functional  Decomposition  of  an  Analysis  Tool. 
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Additionally,  Figure  10  shows  those  functions  in  the  sequence  they  need  to  occur, 
usually  called  a  functional  flow  block  diagram  (FFBD),  in  order  to  support  COA 
Wargaming. 


effbd  Support  Wargame  Analysis 
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Figure  10.  Functional  Flow  Block  Diagram  of  a  Wargame  Analysis  Tool. 

In  Figure  9  and  Figure  10,  the  F.O  function,  Create  COAs,  and  the  F.999,  COA 
Comparison  are  the  starting  and  ending  points  for  the  system.  F.l,  F.2,  and  F.3  are  the 
primary  focus  points  for  this  tool,  and  presumably  LAWST. 

Each  function  can  be  further  broken  down  to  look  at  more  specific  aspects  of  the 
system  as  it  relates  to  lesser  tasks.  These  tasks,  at  a  detailed  level,  are  one  source  of 
system  requirements  that  are  recorded  during  the  requirements  generation  phase.  For 
example,  F.l,  Prepare  for  COA  Wargame  can  be  broken  down  by  looking  at  all  the  tasks 
that  different  entities  have  to  perform  while  preparing  for  a  COA  wargame.  Figure  11 
shows  an  FFBD  in  which  the  S4,  the  logistician,  is  using  the  tool/system  to  accomplish 
the  tasks  necessary  to  prepare  for  a  wargame. 
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This  is  the  beginning  of  the  FFBD  describing  the  logistician  preparing  for  a  COA  wargame;  the 
entire  diagram  can  be  found  in  Appendix  A. 

Figure  11.  FFBD  of  a  Logistician  Using  a  Support  Aid/Tool  While  Preparing 

for  a  COA  Wargame. 


The  FFBD  in  Figure  1 1  includes  the  players  or  nodes  in  the  task,  the  information 

that  is  transferred  between  nodes,  and  the  sequence  of  events  that  each  node  must 

complete  to  accomplish  the  task.  For  this  FFBD,  there  is  an  S4,  the  system  on  which  he 

or  she  is  working,  data  that  the  system  needs  to  contain,  and  external  systems  that 

interact.  This  FFBD  describes  the  following  vignette  from  the  System  Mission  Analysis: 

The  S4  selects  the  map  sets  needed  for  the  operations  area  where  the  mission  will 
take  place  by  entering  an  eight  or  ten-digit  grid  location.  The  system  loads  a  set  of 
maps,  including  digital  terrain  elevation  data  (DTED),  hydrology,  imagery,  and 
standard  MGRS  map  sets.  The  S4  either  imports  COA  graphics  from  an  external 
system  or  creates  the  COA  graphics  on  the  tool.  The  S4  then  determines  the 
usable  routes  or  arcs  that  a  logistics  network  could  use  to  support  the  COA.  The 
S4  also  inputs  friendly  unit  information,  logistics  asset  information,  supply 
locations.  The  S4  sets  parameters  for  each  one,  including  desired  days  of  supply 
(DOS),  supply  capacity  limits,  and  demand.  The  S4  then  creates  a  logistics 
concept  to  support  the  COA  and  task  organizes  logistics  assets  to  support  the 
COA. 
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Another  factor  to  consider  is  the  timing  of  the  functions.  The  MCPP  allocates 
about  20  minutes  during  a  planning  cycle,  in  support  of  operations,  to  developing  COAs. 
Assuming  three  COAs  are  developed,  a  hypothetical  allocation  of  time  for  each  task  is  as 
follows: 

•  Select  Map,  10  seconds 

•  Input  COA  graphics,  40  seconds  per  COA 

•  Input  usable  routes,  40  seconds  per  COA 

•  Input  friendly  unit  locations,  40  seconds  per  COA 

•  Input  friendly  asset  information,  40  seconds  per  COA 

•  Input  friendly  supply  information,  40  seconds  per  COA 

•  Build  task  organization,  40  seconds  per  COA 

•  Input  desired  DOS,  10  seconds  per  COA 

•  Input  capacity  limits,  10  seconds  per  COA 

•  Input  friendly  demand,  10  seconds  per  COA 

•  Create  Concept  for  logistics  support,  180  seconds  per  COA 

These  times  can  be  allocated  in  other  ways  based  on  how  the  customer  wants  to 
trade-off  different  capabilities  of  the  tool.  This  initial  allocation  can  be  adjusted  in 
subsequent  iterations  of  a  requirements  generation  process.  Figure  12  shows  a  snapshot 
of  this  set  of  tasks  associated  with  preparing  for  a  wargame  and  their  timing. 
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CORE  has  a  simulation  mechanism  that  allows  the  timing  to  be  shown  pictorially  for  greater 
understanding  of  the  functions  over  time. 


Figure  12.  Simulated  Times  for  Each  Task  in  an  FFBD  Created  in  CORE. 


In  this  figure,  the  times  combine  to  1200  seconds,  or  20  minutes,  which  is  the 
time  allocated  by  the  MCPP  to  generate  COAs  in  a  rapid  response  planning  timeline. 

A  complete  set  of  FFBDs  and  functional  hierarchy  is  found  in  the  Appendix  A. 

4.  System  Requirements 

System  requirements  come  from  a  variety  of  sources.  Flowever,  all  requirements 
should  have  the  same  general  properties.  Karl  Wiegers  (1999),  writing  on  software 
requirements  states  they  should  be: 

Correct;  a  robust  process  with  feedback  loops  will  ensure  correct 
requirements 

Feasible;  requirements  should  be  attainable  with  the  resources  provided  by 
the  customer. 

Necessary;  they  should  be  traceable  back  to  the  original  problem 
statement. 

Prioritized;  developers  should  understand  the  requirements  that  are  the 
most  important  for  success. 

Unambiguous;  wording  should  be  clearly  understood  by  different 
designers  in  the  same  way. 

Verifiable;  there  should  be  a  way  to  measure  or  confirm  that  a  requirement 
has  been  met. 
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Other  aspects  of  requirements  described  by  Buede  (2009)  include:  complete, 
consistent,  correct.  He  also  stresses  the  need  for  requirements  to  focus  on  defining  the 
problem  to  be  solved  rather  than  the  solution. 

The  primary  source  of  requirements  is  from  the  functional  analysis.  An  initial  set 
of  requirements  is  taken  directly  from  the  functions  on  a  one-for-one  basis.  Care  is  taken 
to  eliminate  redundant  requirements  and  correct  inconsistent  requirements. 

The  first  function  that  will  lead  to  a  requirement  is  “Query  data  for  maps  of 
selected  area.”  An  operator  should  be  able  to  enter  a  grid  coordinate  somewhere  in  the 
area  of  operations  and  find  all  the  associated  maps  with  that  location.  Because  the 
operator  may  be  operating  on  a  ship  and  a  potentially  secure  network,  the  maps  should  be 
readily  accessible.  There  are  other  command  and  control,  intelligence,  and  fires  systems 
that  also  use  maps.  Using  a  standard  mapping  engine  that  already  accepts  those  types  of 
maps  reduces  the  need  to  keep  all  map  sets  resident  on  the  system.  The  requirement  could 
then  be  written  as: 

“The  system  shall  use  a  mapping  engine  that  accepts  CADRG  (MIL-C-89038), 
CIB  (MEL-STD-241 1)  and  DTED  map  data.” 

This  requirement  is  correct:  logistics  networks  are  visualized  on  a  map,  as  are 
COA  graphics  and  both  are  determined  during  the  mission  analysis  phase.  The 
requirement  is  feasible:  there  are  several  open  source  map  engines  that  are  compatible 
with  standard  maps  sets  used  by  the  military.  The  requirement  is  necessary:  it  traces  back 
to  specific  functions  and  tasks  in  the  mission  analysis  phase.  The  requirement  should  be 
prioritized  as  high  priority:  maps  are  a  basis  for  many  types  of  planning  and  wargaming. 
The  requirement  is  clearly-worded.  The  requirement  is  verifiable;  a  demonstration  could 
determine  whether  the  requirement  has  been  met.  This  is  an  acceptable  requirement. 

A  related  requirement  is: 

“The  system  shall  allow  operators  to  select  the  map,  and  display  it  at  a  scale 
necessary  for  planning,  and  location  within  10  seconds.” 
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While  the  time  limitation  seems  arbitrary,  it  is  necessary  in  maintaining  the 
timeline  required  by  a  rapid  response  planning  process  as  described  in  Figure  12.  If  other 
times  during  the  COA  development  phase  of  the  MCPP  could  be  reduced,  then  longer 
times  to  locate  the  appropriate  maps  may  be  acceptable.  This  is  a  good  example  of  a 
requirement  that  can  be  negotiated  with  the  customer.  For  many  of  the  same  reasons  as 
the  previous  requirement,  this  requirement  is  also  acceptable. 

As  related  to  wargaming  specifically: 

“The  system  shall  allow  operators  to  input  branches  and  sequels  identified  at  each 
decision  point  during  the  wargame.” 

Almost  every  version  of  wargaming  involves  decision  points  and  branches.  The 
tool  needs  to  be  able  to  accommodate  this  common  mechanism  in  order  to  be  useful  to 
logisticians  participating  in  a  wargame. 

Other  requirements  may  come  directly  from  the  customer.  For  example,  E20  is  an 
organization  that  is  focused  on  energy  efficiency  so  a  required  element  is  the  total  amount 
of  fuel  used  and  the  rate  at  which  it  used  for  any  given  COA.  That  required  element 
manifests  itself  in  the  following  requirement: 

“The  system  shall  determine  the  overall  fuel  used,  over  time,  for  each  COA.” 

By  examining  the  customer  needs,  mission  tasks,  and  required  functions  designers 
can  determine  the  requirements  for  a  system.  However,  other  sources  of  requirements  are 
often  overlooked  such  as  regulatory  requirements  and  requirements  that  are  derived  from 
best  business  practices. 

Regulatory  requirements  are  often  roadblocks  to  successfully  operating  a  system 
in  its  intended  environment.  For  example,  the  logistics  tool  will  operate  on  the  Navy 
Marine  Corps  Intranet  (NMCI).  In  order  to  operate  on  the  NMCI,  the  tool  must  comply 
with  all  the  applicable  rules,  guidance,  and  certifications  that  govern  the  network  as  per 
the  DON  CIO  Memo  02-10,  26  April  2010:  “The  system  shall  be  compliant  with  all  DoN 
regulations  for  authority  to  operate  (ATO)  on  NMCI  networks.” 
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A  complete  set  of  requirements  developed  during  this  research  is  found  in 
Appendix  B . 

5.  The  Extent  That  LAWST  Fulfills  the  Presumed  Original 
Requirements 

Section  A  in  this  chapter  introduces  the  potential  origins  of  requirements  for 
LAWST.  Half  of  these  assumed  requirements  are  met  by  LAWST  and  can  be  verified  by 
inspection.  For  Requirement  1,  LAWST  can  calculate  supply  and  demand  by  echelon  and 
level.  However,  the  term  zone  is  not  defined  and  there  does  not  seem  to  be  a  clear  way  to 
calculate  supply  and  demand  within  a  specified  portion  of  the  supply  network  using 
LAWST. 

Requirements  2  and  6  seem  straightforward  and  can  be  readily  demonstrated 
using  LAWST  but  the  word  “define”  seems  targeted  to  LAWST.  Since  LAWST  is 
described  in  the  LAWST  documentation  as  a  data  driven  model,  it  is  actually  the  operator 
that  defines  the  throughput,  storage  and  delivery  capability  so  the  requirements  are 
unclear. 

Requirement  3  is  closely  related  to  requirement  5.2  in  that  it  specifies  the  need  to 
determine  the  fuel  consumption  for  a  specific  commodity.  The  difficulty  is  that  LAWST 
does  not  specifically  break  out  the  fuel  cost  of  any  given  commodity  type.  While  the 
commodity  fuel  cost  for  any  given  commodity  type  could  be  determined  artificially  by 
only  including  the  demand  of  that  commodity  in  the  model,  LAWST  does  not  break  out 
fuel  cost  of  any  given  commodity. 

LAWST  does  not  show  any  feature  that  accounts  for  different  types  of  fuel  as 
specified  in  requirement  4.  While  artificialities  could  be  incorporated  such  as  defining  a 
commodity  as  a  second  fuel  type  with  a  specific  demand  for  a  unit,  LAWST  does  not 
inherently  accommodate  two  fuel  types. 

The  final  requirement  is  supported  by  LAWST.  Concepts  that  the  LAWST 
documentation  puts  forward  such  as  Scripted  sorties  can  be  included  to  change  the 
baseline  logistics  network  at  certain  times  and  places. 
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An  overall  assessment  of  LAWST  against  these  articulated  requirements  is  shown 
in  Table  3. 


Table  3.  Summary  of  LAWST  Assessed  Against  Articulated  Requirements 


Requirement 

Degree  that  LAWST  meets  requirement 

Requirement  1 

Partially 

Requirement  2 

Yes 

Requirement  3 

Partially 

Requirement  4 

No 

Requirement  5.1 

Yes 

Requirement  5.2 

Partially 

Requirement  6 

Yes 

Requirement  7 

Yes 

In  summary,  LAWST  fulfills  4/8  of  these  requirements,  partially  addresses  3/8 
requirements,  and  does  not  address  one  requirement. 

If  these  requirements  were  the  correct  requirements  to  which  LAWST  was 
developed,  then  LAWST  failed  to  meet  all  the  requirements  and  may  not  be  suitable  for 
its  intended  purpose.  It  may  be  that  these  are  only  an  initial  set  of  requirements  and 
additional  trade-offs  were  made  prior  to  developing  the  system.  However,  without  a 
record  of  those  negotiations  and  the  outcomes,  there  is  no  conclusive  answer  to  whether 
LAWST  is  valid  for  the  purpose  that  these  requirements  stem  from. 

6.  The  Extent  That  LAWST  Fulfills  Requirements  Generated  by  a 
Systems  Engineering  Approach 

There  are  45  potential  requirements  developed  using  a  systems  engineering 
approach.  Appendix  B  contains  an  assessment  of  how  well  the  current  version  of 
LAWST  meets  the  requirements  that  were  developed  using  a  systems  engineering 
approach.  In  the  interest  of  brevity,  this  section  will  examine  a  sample  of  the  full  set  of 
requirements.  It  presents  a  summary  for  how  the  current  version  of  LAWST  fares  with 
the  requirements  that  were  developed  using  a  systems  engineering  approach.  The 
following,  selected  randomly,  are  examples  of  the  assessments: 
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Requirement  two  states  “The  system  shall  allow  operators  to  select  the 
appropriate  map  and  location  within  10  seconds.”  LAWST  requires  operators  to  upload  a 
picture  of  a  map  and  size  it  correctly  to  the  grid  system  in  the  user  interface  by  matching 
the  corners  of  the  picture  to  a  latitude/longitude  point.  This  process  takes  a  few  minutes 
to  accomplish  and  is  far  from  the  10  seconds  described  in  the  requirement. 

Requirement  eight  states  “The  system  shall  allow  operators  to  set  objective  DOS 
for  friendly  units.”  LAWST  has  a  function  that  allows  operators  to  adjust  the  required 
DOS  for  units  and  logistics  nodes. 

Requirement  16  states,  “The  system  shall  allow  the  creation  of  arcs/routes  for  the 
supply  network  within  40  seconds.”  LAWST  allows  nodes  and  arcs  to  be  created  and 
placed  on  the  map.  There  are  two  ways  to  do  this,  first  by  manually  creating  the  node  or 
arc.  Nodes  are  can  be  placed  on  the  map  by  clicking  on  the  point  on  the  map  or  entering  a 
latitude  or  longitude.  Arcs  are  defined  between  two  different  nodes.  The  second  way  to 
produce  the  nodes  and  arcs  is  to  define  them  all  in  a  Microsoft  Excel  spreadsheet  and 
adjust  the  configuration  file  to  call  that  spreadsheet.  This  requirement  can  be  met 
depending  on  the  situation.  If  the  nodes  and  arcs  are  pre-defined  and  readily  available  in 
an  Excel  file,  in  the  proper  format,  LAWST  can  meet  this  requirement.  If  the  nodes  and 
arcs  must  be  manually  entered,  this  can  take  on  the  order  of  minutes  to  hours  depending 
on  the  complexity  of  the  network.  In  this  case,  LAWST  would  not  meet  the  requirement. 

Requirement  23  states  “The  system  shall  allow  operators  to  evaluate  the  state  of 
the  logistics  networks  at  each  branch  and  sequel  of  an  operation.”  LAWST  allows  one 
network  at  a  time  to  be  evaluated.  Additional  branches  and  sequels  would  need  to  be 
evaluated  as  separate  networks.  This  could  be  accomplished  by  adjusting  the  nodes,  arcs, 
unit  locations,  and  other  relevant  portions  of  the  network  and  re-evaluating.  Re-adjusting 
elements  in  the  network  may  take  several  minutes  and  not  be  useful  within  the  time 
constraints  of  a  fast-paced  wargame.  In  the  case  of  a  rapid  response  planning  process,  the 
wargame  of  a  single  COA  may  only  take  about  five  minutes.  While  LAWST  can  evaluate 
different  networks,  comparing  a  network  with  several  branches  and  sequels  is  infeasible 
for  the  software:  LAWST  would  not  meet  this  requirement. 
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Requirement  31  states,  “The  system  shall  determine  the  number  of  excess 
transportation  assets  within  the  logistics  network  over  time.”  LAWST  can  determine  the 
utilization  rate  of  transportation  assets  at  a  logistics  node.  This  is  a  derivative  piece  of 
information  based  on  the  number  of  assets  being  used  over  a  period  of  time.  With 
relatively  little  effort,  a  logistician  can  determine  where  in  the  network  there  are  available 
transportation  assets;  therefore,  LAWST  fulfills  this  requirement. 

Overall,  the  current  version  of  LAWST  meets  24/45  requirements  that  were 
developed  using  a  systems  engineering  approach.  The  remaining  requirements  would  not 
be  achieved  by  LAWST  without  substantial  investment  of  additional  time,  money,  and 
effort. 


C.  COMPARE  THE  REQUIREMENTS  SETS 

There  are  several  differences  between  the  requirements  sets,  namely  the  number 
and  detail  of  requirements,  the  traceability  of  the  requirements,  and  the  type  of 
requirements.  The  larger  number  of  requirements  is  typically  due  to  a  clearer 
understanding  of  the  functions  that  the  system  must  perform.  Traceability  means  that  the 
requirement  has  a  reason  that  supports  the  analysis  in  a  previous  step  of  the  design 
process.  The  different  types  of  requirements  usually  stem  from  different  viewpoints  being 
evaluated  as  part  of  a  design  process. 

The  original  seven  LAWST  requirements  stemmed  from  the  need  to  analyze  a 
specific  event,  the  EF-21  Energy  Study  and  Operational  Reach  Wargame.  The 
requirements  are  focused  on  answering  the  questions  that  the  study  aimed  to  answer, 
which  is  reasonable,  if  the  tool  is  meant  only  to  be  valid  for  the  specific  wargame.  On  the 
other  hand,  if  the  tool  was  meant  to  address  EF-21  Energy  studies  beyond  the  wargame, 
additional  information  should  have  been  considered  during  development.  With  a  systems 
engineering  approach,  the  problem  is  analyzed  with  a  more  rigorous  stakeholder  analysis 
that  uncovers  additional  uses  for  the  system  beyond  the  short-term  problem.  The 
expanded  problem  set  uncovers  additional  uses  and  required  functions  that  need  to  be 
accounted.  Thus,  the  SE-developed  requirements  are  more  thorough  in  addressing  the 
aspects  of  the  system  that  the  customer  desires. 
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The  traceability  of  the  requirements  is  an  important  aspect  of  any  system 
requirement.  It  ensures  that  system  specifications  will  produce  a  capability  that  can 
address  the  problem  for  which  it  was  designed.  The  assumed  original  requirements 
provided  by  Group  W  included  a  linkage  between  each  of  the  requirements  and  a  specific 
question  asked  in  the  EF-21  Energy  Study  and  Operational  Reach  Wargame  concept. 
This  indicates  that  a  system  developed  to  this  requirement  set  would  be  valid  for 
participating  in  Operational  Reach  or  any  other  application  with  the  same  limited  scope. 
The  requirements  developed  through  a  systems  engineering  approach  have  traceability 
that  is  examined  through  operational  planning  and  wargaming  procedures,  as  well  as  a 
wider  scope  of  questions  that  would  specify  a  system  that  is  useful  for  a  larger  range  of 
applications  and  uses. 

The  types  of  requirements  that  are  developed  using  these  two  approaches  are 
significantly  different.  With  the  original  requirements  set,  the  focus  of  the  requirements  is 
mainly  on  construction  of  the  logistics  network,  what  factors  an  operator  needs  to  control, 
and  how  to  analyze  the  data.  These  requirements  were  tailored  to  support  a  single 
seminar  wargame  that  did  not  require  immediate  results.  The  systems  engineering 
approach  developed  additional  types  of  requirements.  Usability  requirements,  not 
addressed  with  the  original  system  requirements,  addressed  the  time  constraints  that 
operators  had  to  work  in  when  they  are  participating  in  a  planning  process.  The  systems 
engineering  approach  also  uncovered  interoperability  requirements  based  on  the 
environment  within  which  the  system  would  be  operating.  Additionally,  the  stakeholder 
analysis  produced  the  need  for  a  system  to  help  operators  identify  ways  to  adjust  the 
logistics  network  to  overcome  problems  that  arise  during  the  construction  of  the  network 
or  the  wargame. 

The  systems  engineering  approach  produces  requirements  that  not  only  address 
the  customers  immediate  issues  but  also  get  to  the  root  of  the  problem  that  the  customer 
has.  It  produces  requirements  that  address  a  larger  range  of  capabilities  that  a  system 
needs  to  have,  and  by  more  thoroughly  analyzing  the  problem,  produces  a  more  robust 
system  than  would  otherwise  be  realized. 
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An  additional  insight  here  is  that  there  are  no  requirements  oriented  to  operations 
at  a  tactical  or  operational  level  in  the  presumed  original  requirements  so  therefore,  the 
problem  that  drove  the  original  requirements  is  not  the  one  stated  in  the  problem 
definition  (from  the  SE  approach).  In  other  words,  the  problem  that  E20  wants  LAWST 
to  address  is  not  the  problem  that  it  was  developed  to  address. 

D.  QUANTIFYING  DIFFERENCES  IN  APPROACHES 

We  use  two  methods  to  quantify  the  approaches:  work  breakdown  structure  and 
value  tree.  A  work  break  down  structure  shows  the  resource  requirements  for  individual 
parts  of  a  system  as  they  are  related  to  the  total  development  of  the  system.  An  objectives 
tree  reflects  the  interests  that  a  stakeholder  has  in  developing  a  system. 

There  are  some  difficulties  for  quantifying  the  differences  in  the  processes  that 
produced  the  two  requirement  sets.  To  begin  with,  the  problem  statements  that  produced 
the  two  sets  of  requirements  are  potentially  different  since  there  is  no  documented 
version  of  the  problem  statement  for  the  original  version  of  LAWST.  The  only  viable 
process  available  to  us  for  this  analysis  is  the  systems  engineering  approach.  There  is  no 
one-for-one  mapping  between  requirements  from  the  two  sets.  Additionally,  each 
requirement  has  a  different  level  of  effort  associated,  with  respect  to  the  resources 
required  to  realize  it  in  a  system.  The  following  analysis  recognizes  these  issues  and  for 
the  sake  of  discussion  makes  the  following  assumptions: 

•  There  are  five  types  of  requirements  that  can  be  discerned;  usability, 
model/simulation,  analysis,  interoperability,  and  optimization. 

•  Each  requirement,  within  a  set  of  requirements,  needs  the  same  level  of 
effort  to  incorporate  into  a  system.  No  weighting  is  applied  to  any  one 
type  of  requirement. 

•  The  requirements  lists  are  complete.  That  is,  the  list  is  agreed  upon  by 
both  the  customer  and  developer. 

•  The  model/simulation  level  of  effort  between  the  two  requirements  sets 
will  be  the  same  level  of  effort  in  order  to  compare  the  sets. 

•  A  work  breakdown  structure  (WBS)  will  be  used  to  compare  the 
requirements  sets 
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Consider  the  level  of  effort  for  the  first  set  of  requirements  to  be  100  hours  of 
work  to  realize  System  A  using  the  eight  requirements  listed  in  Section  C  of  this  chapter. 
Half  of  the  work  is  done  on  model/simulation  requirements  and  the  other  half  is  on 
analysis  requirements  so  a  WBS  for  this  system  would  look  as  shown  in  Figure  13. 


Figure  13.  Notional  WBS  for  System  A. 


Now  consider  a  system,  System  B,  developed  against  the  set  of  requirements 
generated  using  a  system  engineering  process  and  as  seen  in  Figure  14.  Here  the  45 
requirements  are  organized  into  five  categories:  six  requirements  are  usability 
requirements,  three  are  interoperability,  18  are  related  to  model/simulation,  16  are 
analysis,  and  two  are  optimization. 


Figure  14.  Notional  WBS  for  System  B  Developed  Using  a  Systems 

Engineering  Approach. 


Recall  the  assumption  that  the  model/simulation  level  of  effort  between  the  two 
systems  would  be  proportional.  Then  with  System  B,  keeping  the  model/simulation  effort 
proportional  to  that  in  System  A,  then  takes  125  hours  to  complete.  The  general  insight  is 
that  a  system  developed  using  a  systems  engineering  approach  will  take  more  time  to 

develop  when  compared  to  an  undirected  requirements  development  process. 
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Now,  recall  the  extent  to  which  LAWST  meets  the  requirements  developed  using 
a  systems  engineering  approach.  If  partially  met  requirements  only  count  as  one-half  of  a 
met  requirement,  then  LAWST  achieved  28.5  requirements  of  45  requirements  or  63%, 
leaving  37%  of  requirements  unmet.  If  LAWST  was  developed  in  100  hours  as  in  System 
A  and  only  fulfills  63%  of  the  requirements,  then  the  rework  required  to  meet  the  rest  of 
the  37%  of  the  requirements  is  about  58  more  hours.  This  brings  the  total  number  of 
hours  for  System  A  to  meet  the  requirements  for  System  B  to  about  158  hours. 

The  point  here  is  that  a  system  developed  against  a  set  of  SE  requirements  may 
appear  to  be  more  expensive  to  produce.  However,  if  a  system  is  not  produced  using  a 
systems  engineering  approach  and  requires  rework  to  meet  that  set  of  requirements,  it 
will  be  more  expensive,  in  terms  of  level  of  effort,  in  the  end. 

The  numbers  presented  here  provide  anecdotal  evidence  of  the  increased  cost 
when  not  using  a  systems  engineering  process  that  reflects  a  58%  increase  in  recourse 
requirements.  GAO  reports  that  actual  program  cost  increases  due  to  changing 
requirements  have  been  anywhere  between  23%— 1 14%  of  initial  cost  baselines  (GAO 
2015).  The  result  from  this  analysis  is  within  the  range  of  the  GAO  reports. 

Another  way  to  look  at  the  different  approaches  to  requirements  generation  is  by 
looking  at  an  objectives  tree  for  the  customer,  E20,  and  compare  it  to  the  requirements 
sets  and  determine  to  what  extent  the  different  approaches  support  E20’s  objectives.  In 
the  Problem  Definition  phase  of  the  systems  engineering  process,  the  research  explored 
high-level  interests  of  E20,  specifically  around  the  efficient  use  of  resources  and 
influencing  the  way  the  Marine  Corps  employs  its  energy  and  resources  during 
operations.  When  it  comes  to  efficient  use  of  resources,  analysis  and  optimization  are  key 
aspects  of  addressing  that  objective.  Likewise,  interoperability  and  usability  are  key 
aspects  of  getting  tools  to  Marines  at  the  lowest  level  where  they  can  be  easily  employed 
and  affect  change  in  the  way  they  think  about  and  use  energy  and  other  resources. 
Another  broader  category  of  objectives  would  be  to  provide  general  information  and  tools 
to  the  Marine  Corps  in  managing  the  complex  issues  around  managing  energy  and 
resources.  E20  concurred  with  the  following  weights  in  Table  4. 
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Table  4.  Weighting  for  the  Categories  of  Requirements  and  Factors  Related 

to  E20  Objectives. 


Factor 

Weight 

Analysis 

0.25 

Optimization 

0.15 

Interoperability 

0.1 

Usability 

0.2 

Model/S  imulation 

0.3 

Total 

1 

A  reasonable  objectives  tree  with  weighting  for  this  organization  is  in  Figure  15: 


Figure  15.  Objectives  Tree  for  E20. 


The  factors  organized  under  the  organization’s  objectives  add  to  100%,  for 
example,  the  objective  “Efficient  use  of  resources”  has  two  factors:  Analysis  and 
Optimization.  While  the  weights  of  the  factors  are  0.25  and  0.15  respectively,  their 
relative  weights,  0.625  and  0.375  add  to  1  or  make  up  100%  of  the  factors  for  “Efficient 
use  of  resources.”  Now,  if  the  different  approaches  to  requirements  generation  are 
compared  in  this  way,  the  requirements  developed  using  a  systems  engineering  approach 
address  all  the  objectives  of  the  organization  where  the  assumed  original  requirements 
only  address  55%  of  the  organizations  objectives.  The  shortfalls  of  the  assumed  original 
requirements  being  a  tool  that  is  interoperable  and  usable  at  the  lowest  levels  and  the 
ability  to  optimize  the  use  of  resources. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY  OF  RESULTS  AND  INSIGHTS 

The  methodology  described  in  chapter  III  outlines  a  process  by  which  the  process 
that  was  used  to  develop  systems  requirements  for  LAWST  is  compared  to  a  systems 
engineering  process  for  developing  system  requirements.  Since  LAWST  is  a  system  that 
has  already  been  developed  and  used  by  E20  in  evaluating  energy  distribution,  the 
evaluation  of  the  current  requirements  and  the  process  by  which  they  were  developed  is 
primarily  an  investigation  of  current  documentation  regarding  the  system. 

LAWST  is  a  useful  tool  for  seminar  wargames  such  as  the  EF-21  Energy  Study 
and  Operational  Reach  Wargame.  It  was  designed  to  complement  MPEM’s  operational 
unit  energy  demand  with  the  demand  produced  by  the  logistics  network  used  to  deliver 
those  energy  resources.  The  results  provide  an  estimate  of  risk  and  give  some  indication 
as  to  where  problems  in  the  logistics  network  may  be.  Outside  the  scope  of  this  specific 
seminar  wargame,  the  system  has  limited  utility  since  it  is  not  designed  with  a  larger 
scope. 

LAWST  is  insufficient  at  the  tactical  level,  battalion  and  brigade,  for  planning  and 
evaluating  logistics  networks.  The  primary  reason  for  this  is  its  inability  to  support  the 
timelines  required  to  build  COAs,  wargame,  and  evaluate  those  COAs.  In  cases  such  as  a 
rapid  response  planning  process,  there  are  only  4  hours  between  the  receipt  of  a  mission 
and  the  distribution  of  orders.  LAWST  is  designed  for  overnight  analysis  of  a  logistics 
network  and  cannot  support  such  planning. 

System  requirements  developed  using  a  systems  engineering  method  start  with  a 
problem  definition  based  on  E20  comments  and  documentation.  The  problem  is  further 
refined  by  including  the  context  of  the  mission  in,  which  the  system  will  be  involved. 
This  additional  specification  differs  from  the  original  process  that  drove  the  current 
version  of  LAWST  in  that  it  includes  the  system’s  use  at  the  tactical  and  operational 
level.  A  functional  analysis  breaks  down  the  functions  of  the  system  which  leads  to 
system  requirements.  Those  system  requirements  developed  using  a  systems  engineering 
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approach  show  a  distinct  difference  to  the  original  requirements  in  that  they  have 
additional  emphasis  on  interoperability,  usability  and  optimization  type  requirements.  A 
brief  analysis  of  LAWST  indicates  that  the  system  meets  24  of  the  45  requirements. 

The  research  shows,  using  LAWST  as  an  example,  which  the  costs  for  changing 
the  system  after  it  has  been  developed  are  greater  than  if  the  system  were  developed 
correctly  in  the  first  place.  Additionally,  supporting  data  from  GAO  indicates  program 
costs  increasing  over  100%  of  initial  costs  because  of  changes  to  requirements  (GAO 
2015).  This  supports  the  need  for  a  systems  engineering  approach  to  developing  systems, 
especially  earlier  in  the  process  prior  in  examining  the  problem  and  developing 
requirements. 

B.  CONCLUSIONS 

There  are  a  number  of  questions  that  this  research  answers: 

1.  How  Were  the  Design  Requirements  Established  for  the  Development 
of  LAWST? 

There  is  evidence  in  Chapter  IV,  Section  A,  which  was  provided  by  E20  and 
Group  W,  which  shows  a  directed  modeling  effort,  in  parallel  with  MPEM  that  will 
support  a  wargame  and  study.  Additionally,  Group  W  provided  a  presentation  that 
outlines  the  proposed  support  for  the  EF-21  Energy  Study  and  Operational  Reach 
Wargame  (Group  W,  unpublished  document).  In  that  presentation,  the  questions  posed  in 
Operational  Reach  are  directly  linked  to  proposed  solution  requirements  that  are 
evaluated  in  Chapter  IV,  Section  C.  It  follows  that  this  is  how  the  design  requirements 
were  established  for  the  development  of  LAWST.  If  this  is  indeed  the  case,  an  assertion 
can  be  made  that  LAWST  could  be  valid  as  a  tool  to  assist  analysts,  during  a  deliberate 
seminar  type  wargame,  in  evaluating  the  energy  consumption  of  the  logistics  network, 
while  delivering  supplies  to  maneuver  units  whose  energy  demand  is  modeled  through 
MPEM.  This  assumes  that  the  model  can  be  verified  to  be  correct  within  some  defined 
tolerance  against  empirical  data.  Outside  of  that  scope,  there  is  little  evidence  that 
LAWST  would  be  valid. 
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2.  What  Would  the  System  Requirements  for  LAWST  Be  if  a  Systems 
Engineering  Approach  Had  Been  Used? 

This  research  begins  by  defining  the  problem.  Information  from  E20  indicates 
that  the  organization  is  interested  in  improving  the  way  the  Marine  Corps  supports 
operations  from  a  perspective  of  energy  efficiency.  This  is  partly  accomplished  by 
equipping  Marines  with  tools  geared  towards  operating  in  a  more  expeditionary  manner. 
It  seems  that  the  original  requirements  did  not  capture  the  need  to  use  LAWST  in  a 
tactical  or  operational  environment  and,  therefore,  did  not  accommodate  the  type  of 
functions  and  usability  features  that  are  necessary  at  that  level. 

The  systems  engineering  method  for  requirements  generation  stresses  starting 
with  the  proper  question  and  understanding  the  environment  in  which  the  system  will 
operate.  In  the  case  of  LAWST,  wargaming  in  the  context  of  planning  for  a  mission  in  a 
time  constrained  environment  is  significantly  different  from  a  wargame  conducted  as  part 
of  a  study  conducted  over  several  weeks  Blanchard  and  Labrycky  (2011)  state  that  the 
application  of  systems  engineering  can  “  help  promote  greater  design  maturity  earlier.”  (p 
64)  The  systems  engineering  method  for  requirements  generation  produces  a  larger 
variety  of  requirements  because  of  the  greater  scope  of  viewpoints  that  are  examined. 
Adding  further  support:  “Without  sufficient  systems  engineering  input  to  better  define 
requirements  and  examine  trade-offs  early  on,  there  is  no  assurance  that  acquisition 
programs  going  forward  have  a  sound  basis  to  start  system  development.”  (GAO  2015, 
20)  The  requirements  developed  for  this  research  along  with  a  brief  explanation  of  each  is 
found  in  Appendix  B. 

3.  Does  the  Current  Version  of  LAWST  Address  the  System 
Requirements  That  Would  Have  Been  Developed  through  a  Systems 
Engineering  Approach? 

The  Logistics  Analysis  and  Wargame  Support  Tool,  if  evaluated,  would  most 
likely  meet  a  majority  of  the  requirements  in  Appendix  B.  There  are  two  primary 
shortfalls  with  the  current  version  of  LAWST,  as  it  relates  to  requirements  developed 
using  a  systems  engineering  approach:  usability  and  interoperability. 
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Usability  is  generally  a  function  of  how  easy  the  system  is  to  use.  The  drivers  for 
usability  can  come  from  two  places:  the  mission  that  the  system  must  participate  in  and 
other  factors  like  amount  of  training.  In  this  case,  the  amount  of  training  was  not  taken 
into  account  with  this  specific  iteration  of  the  systems  engineering  method;  however,  a 
majority  of  the  usability  requirements  are  produced  specifically  because  of  the  mission 
that  the  system  will  be  used  for.  If  LAWST  is  to  be  used  to  evaluate  a  logistics  network 
as  part  of  a  planning  process,  the  ease  of  use  and  the  speed  at  which  operators  can  use  the 
tool  is  critical. 

Interoperability  is  important  because  of  the  environment  within  which  the  system 
operates  and  the  tasks  that  it  must  perform.  From  the  mission  analysis,  LAWST  would 
operate  in  a  tactical  environment  and  need  to  interact  with  other  systems  used  for 
planning  operations.  It  would  be  required  to  operate  on  the  same  network  where  other 
planning  tools  are  being  used  and  need  to  both  share  and  provide  data  to  those  systems. 
LAWST  was  designed  as  a  stand-alone  system  so  these  aspects  have  not  been  addressed. 

The  requirements  that  supposedly  drove  the  design  of  LAWST  are  not 
specifically  traced  to  any  problem  or  gap  that  the  system  is  addressing.  Documentation 
from  E20  shows  linkage  between  requirements  and  questions  from  Operational  Reach; 
however,  there  is  no  other  evidence  of  verbal  or  written  linkage  to  any  problem. 
Establishing  validity  of  the  model  is  impossible  without  linking  it  back  to  the  problem 
that  LAWST  was  designed  to  address. 

LAWST  does  not  meet  E20  system  objectives.  LAWST  is  not  postured  to  meet 
the  demands  of  VV&A  because  there  is  little  documentation  on  the  process  used  in 
designing  the  system.  Lurthermore,  the  E20  requirements  development  provides  an 
inadequate  foundation  for  valid  improvements  to  LAWST  or  as  a  means  to  assess  the 
degree  LAWST  meets  E20  needs. 
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c. 


RECOMMENDATIONS 


1.  Framework  for  Future  Development 

E20  should  adopt  a  method  to  guide  future  development,  in  order  to  reduce  time 
necessary  to  deliver  capabilities  to  the  field,  reduce  resources  necessary  for  development, 
and  produce  more  positive  outcomes  in  early  deliverables.  We  recommend  that  the 
systems  engineering  process  guide  those  future  developments.  Incorporating  such  a 
process  increases  the  likelihood  of  delivering  products  that  are  more  immediately  useful 
to  the  goals  of  E20. 

A  simple  process,  similar  to  that  used  in  this  research,  that  E20  can  use  in 
generating  requirements  can  be  found  in  Figure  16  and  explained  in  the  following 
narrative: 


Systems  Engineering 
Method  for  Requirements 
Generation 


Mission/Context 

Analysis 


Functional 

Analysis 

Performance 

Requirements 

Requirements 

Trade-off 

System 

Requirements 


Figure  16.  Model  for  Requirements  Generation  Using  a  Systems  Engineering 

Approach. 
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This  model  is  a  simple  graphic  that  describes  how  to  develop  system  requirements 
using  a  systems  engineering  approach. 

•  Step  1,  Problem  Definition:  Determine  what  the  problem  or  gap  that  the 
system  is  addressing.  Get  to  the  root  of  why  the  system  is  being  developed 
by  talking  to  relevant  stakeholders  and  examining  related  topics. 

•  Step  2,  Mission  Analysis:  Determine  where  the  system  will  be  used,  how 
it  will  interact  with  operators,  other  systems,  and  its  environment. 
Determine  the  tasks  that  the  system  will  be  used  for,  what  information  is 
needed  to  conduct  the  task,  what  information  the  system  must  provide  or 
action  that  the  system  must  complete  as  part  of  its  operation  in  completing 
the  task.  Describe  the  timing  of  the  task,  is  it  time  dependent;  near  real 
time,  is  timing  prescribed,  or  does  time  not  matter.  Determine  the  system 
operator,  level  of  training,  knowledge  of  the  task  being  conducted,  or 
physical  limitations. 

•  Step  3,  Functional  Analysis:  Determine  the  functions  of  the  system;  what 
actions  the  system  must  complete  as  part  of  its  operation.  Use  information 
from  the  mission  analysis  to  support  the  functional  analysis  to  ensure 
proper  traceability. 

•  Step  4,  Performance  Requirements:  Determine  a  set  of  requirements  that 
can  be  communicated  to  a  developer  to  design  the  system.  The 
requirements  should  be  focused  on  the  functions  that  the  system  must 
perform  as  part  of  its  operation.  Capture  both  functional  requirements  as 
related  to  the  functional  analysis  and  non-functional  requirements  that  are 
related  to  other  aspects  as  described  in  the  mission  analysis. 

•  Step  5,  Requirements  Trade-off:  Determine  the  time  and  resources 
available  to  develop  the  system  and  make  necessary  trade-offs  to  system 
capability.  This  may  require  re-examining  the  problem  definition,  mission 
analysis,  and  functional  analysis  to  get  the  right  balance  of  capability  for 
resources  available. 

2.  Future  Work 

E20  has  expressed  interest  in  validating  LAWST  for  use  by  the  Marine  Corps. 
The  scope  for  what  uses  LAWST  could  be  valid  is  somewhat  limited  by  how  it  was 
designed,  as  well  as  the  actual  tasks  that  it  can  perform.  If  the  desire  is  to  use  the  tool  as 
an  aid  in  planning  and  analyzing  logistics  networks  at  the  tactical  level,  additional 
considerations  such  as  interoperability  and  usability  should  be  taken  into  account  for 
further  development.  The  additional  capabilities  that  LAWST  may  require  should  be 
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carefully  considered  when  determining  if  the  system  should  be  significantly  changed  (i.e., 
new  development)  to  address  the  capability  or  the  system  should  be  moderately  changed 
(i.e.,  new  interface  or  built  in  tools)  to  rectify  the  shortcomings.  A  deliberate  analysis 
should  be  conducted  to  determine  the  best  way  to  address  this,  in  many  cases  it  may  seem 
easier  to  adjust  existing  systems  rather  than  starting  from  the  beginning  but  this  may  turn 
out  to  have  a  much  larger  resource  impact  than  anticipated  (Blanchard  201 1). 

There  are  also  additional  areas  to  explore  in  relation  to  LAWST.  LAWST  relies 
on  energy  usage  data  from  MPEM.  Perhaps  other  areas  where  LAWST  makes 
assumptions  to  simplify  the  analysis  such  as  resupply  scheduling  could  also  be 
incorporated.  For  instance,  in  an  in-process  review  to  E20  in  April  2017,  one  project 
introduced  the  concept  of  “Scheduling  Ship  to  Shore  Fuel  Deliveries”;  this  area  is  one 
that  LAWST  assumes  certain  information  which  may  or  may  not  be  there.  LAWST 
assumes  that,  at  a  logistics  node,  there  is  a  pool  of  available  vehicles  with  an  available 
amount  of  time  and  capacity.  As  long  as  the  availability  is  met,  LAWST  does  not 
explicitly  define  which  assets  deliver  which  supplies.  E20  should  use  this  type  of  tool  to 
evaluate  the  assumptions  made  in  the  development  of  LAWST. 
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APPENDIX  A.  SYSTEM  ENGINEERING  ARTIFACTS 


A.  MIND-MAP  FOR  TOPICS  RELATED  TO  LOGISTICS 
NETWORKS 
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APPENDIX  B.  REQUIREMENTS  FROM  A  SYSTEMS 
ENGINEERING  PROCESS 


1.  The  system  shall  use  a  mapping  engine  that  accepts  CADRG  (MIL-C- 
89038),  CIB  (MIL-STD-2411)  and  DTED  map  data. 

This  requirement  is  linked  to  the  requirements  analysis  and  is  related  to  a 
planning  scenario  where  the  logistics  tool  may  be  located  on  a  secure  network  with 
limited  access  to  commercial  maps.  Standard  mapping  engines  will  accommodate  readily 
available  military  maps  and  DTED. 

LAWST  loes  if  it  meet  this  requirement. 

2.  The  system  shall  allow  operators  to  select  the  map,  and  display  it  at  a  scale 
necessary  for  planning,  and  location  within  10  seconds. 

This  requirement  is  based  on  the  time  constraints  related  to  creating  the  support 
concepts  for  three  COAs  in  a  20-minute  timeframe. 

LAWST  meet  this  requirement. 

3.  The  system  shall  allow  operators  to  define  non-standard  friendly  assets. 

Requirement  based  on  mission  analysis  and  potential  task  that  an  S4  must 
execute. 

LAWST  meets  this  requirement. 

4.  The  system  shall  allow  operators  to  define  non-standard  supply  types. 

Requirement  based  on  mission  analysis  and  potential  task  that  an  S4  must 
execute. 


LAWST  meets  this  requirement. 

5.  The  system  shall  allow  operators  to  create  a  task  organization  based  on 
available  friendly  units  and  assets  within  40  seconds. 

This  requirement  is  based  on  the  time  constraints  related  to  creating  the  support 
concepts  for  three  COAs  in  a  20-minute  timeframe. 


LAWST 


|  meet  this  requirement. 
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6.  The  system  shall  allow  operators  to  create  a  scheme  of  maneuver  for  the 
logistics  network. 

Requirement  based  on  mission  analysis  and  potential  task  that  an  S4  must 
execute. 


LAWST  meets  this  requirement. 

7.  The  system  shall  allow  operators  to  set  the  maximum  capacity  for  each 
friendly  asset  and  unit. 


Requirement  based  on  mission  analysis  and  potential  task  that  an  S4  must 


execute. 


LAWST  meets  this  requirement. 


8.  The  system  shall  allow  operators  to  set  objective  DOS  (Days  of  Supply) 
for  friendly  units. 

Requirement  based  on  mission  analysis  for  S4  to  vary  the  DOS  based  on 
mission  requirements  and  COA. 

LAWST  meets  this  requirement. 

9.  The  system  shall  allow  operators  to  input  supply  consumption,  based  on 
OPTEMPO,  for  each  type  of  friendly  asset. 

This  requirement  is  based  on  the  mission  analysis  and  the  requirement  to  surge  or 
maintain  supply  levels 

LAWST  meets  this  requirement. 

10.  The  system  shall  allow  the  input  or  import  of  friendly  unit  information. 

This  is  a  requirement  from  the  Mission  analysis,  during  the  planning  process,  the 
S4  needs  to  determine  available  forces  to  support  a  COA. 


LAWST  meets  this  requirement 
11. 


The  system  shall  allow  operators  in  upload  friendly  asset  information  from 
an  external  file. 


Information  should  be  available  for  operators  to  upload.  Creating  data  bases  for 
every  unit  is  time  intensive  and  infeasible  during  a  planning  process. 
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LAWST  meets  this  requirement. 

12.  The  system  shall  allow  operators  to  input  Friendly  asset  information 
manually. 

This  requirement  is  related  to  requirement  11. 


LAWST  meets  this  requirement. 

13.  The  system  shall  provide  a  mechanism  to  input  friendly  maneuver 
graphics  within  40  seconds. 

Logisticians  need  a  basic  framework  of  a  COA  to  build  the  network  that  supports 
his  or  her  units. 


LAWST  meet  this  requirement. 

14.  The  system  shall  provide  a  mechanism  to  input  or  import  friendly  unit’s 
locations  within  40  seconds. 


Friendly  unit  locations  during  each  phase  of  the  operation  are  required  by  the 
logistician  in  order  to  determine  the  delivery  of  supplies  to  that  unit.  When  the  operations 
planners  develop  the  COAs,  the  unit’s  locations  are  included. 

LAWST  partially  meets  this  requirement.  LAWST  can  input  locations  but  will  not 
meet  time  constraints.  Even  in  a  spreadsheet,  a  logistician  needs  to  determine  unit  names, 
locations,  and  unit  type  during  COA  development. 

15.  The  system  shall  provide  a  mechanism  to  input  supply  levels  at  every  node 
in  the  network  within  40  seconds. 


Known  quantity  of  supplies  is  necessary  to  prioritize  logistics  activities  and 
understand  urgency  and  risk  in  the  logistics  network. 

LAWST  partially  meets  this  requirement.  LAWST  allows  operators  to  specify 
supply  levels  at  every  node,  however  time  constraints  will  not  be  met,  similar  to 
requirement  14. 

16.  The  system  shall  allow  the  creation  of  arcs/routes  for  the  supply  network 
within  40  seconds. 


Logisticians  must  define  the  routes  that  will  be  used  during  an  operation  but  have 
limited  time  to  build  the  structure  of  the  supply  network  during  the  COA  development. 
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LAWST  partially  meets  this  requirement.  While  the  arcs  and  routes  can  be 
created  quickly  with  pre-defined  points,  it  is  infeasible  to  create  them  all  within  40 
seconds. 


17.  The  system  shall  be  compliant  with  all  DoN  regulations  for  authority  to 
operate  (ATO)  on  NMCI  networks. 

This  is  a  regulatory  requirement  that  has  little  to  do  with  the  actual  operation  of  a 
system.  However,  a  system  that  cannot  achieve  an  ATO  is  generally  not  used  because  of 
the  difficulty  associated  with  standalone  machines. 


LAWST  can  achieve  this  requirement  by  working  through  the  ATO  process. 


During  War  game: 

Assume  5  minutes  per  COA,  2  branches  or  sequels  per  COA 


18.  The  system  shall  allow  operators  to  input  branches  and  sequels  identified 
at  each  decision  point  during  the  wargame. 

This  is  required  during  a  wargame  as  per  the  MCPP. 

LAWST  meet  this  requirement.  It  requires  a  separate  file  per  COA. 

19.  The  system  shall  allow  operators  to  record  wargame  events  in  order  to 
modify  logistics  network. 

Often,  COAs  are  changed  during  a  wargame  to  accommodate  for  reactions  and 
counteractions  that  are  identified  during  the  wargame.  These  reactions  and  counteractions 
are  generally  global  and  require  changes  across  all  platforms 


LAWST  meets  this  requirement. 

20.  The  system  shall  allow  operators  to  see  immediate  results  (less  than  10 
seconds)  of  modifying  the  logistics  network  based  on  enemy  action. 


The  facilitator  of  a  wargame  may  ask  questions  of  functional  area  representatives 
such  as  logisticians  that  require  a  near  immediate  response  in  order  to  synchronize  all 
functions  and  to  understand  the  repercussions  of  any  action  or  counteraction. 


LAWST  meets  this  requirement. 

21.  The  system  shall  allow  operators  to  evaluate  the  state  of  the  logistics 
network  for  a  specific  unit  over  time. 
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During  a  wargame  where  the  facilitator  prescribes  an  avenue-in-depth  method,  a 
logistician  needs  to  be  able  to  follow  a  unit  or  number  of  units  to  from  start  to  finish 
during  an  operation. 

LAWST  meets  this  requirement. 

22.  The  system  shall  allow  operators  to  evaluate  the  state  of  the  logistics 
network  at  each  phase  of  an  operation. 

Like  avenue-in-depth,  if  a  facilitator  chooses  to  look  at  COAs  by  phase,  a  tool 
must  be  able  to  accommodate  this  method. 


LAWST  meets  this  requirement. 

23.  The  system  shall  allow  operators  to  evaluate  the  state  of  the  logistics 
networks  at  each  branch  and  sequel  of  an  operation. 


Every  decision  point  identified  by  the  facilitator  of  a  wargame  usually  has  a 
branch  or  sequel  associated  with  it.  A  system  supporting  the  logistician  must  be  able  to 
evaluate  any  branch,  sequel  or  combination. 


LAWST  meet  this  requirement.  As  described  in  Chapter  IV. 

24.  The  system  shall  allow  operators  to  evaluate  the  state  of  the  logistics 
networks  at  specified  times  during  an  operation. 

Another  method  for  wargaming  is  key  event  method;  this  is  where  the  facilitator 
looks  at  specific  times  and  places  in  a  COA  during  a  wargame. 

LAWST  meets  this  requirement. 

25.  The  system  shall  model  units  down  to  the  platoon  level  (T),  or  the 
individual  platform  or  Marine  (O). 

Wargaming  at  any  given  echelon  usually  explores  units  two  levels  down;  for 
example,  at  battalion  level,  wargames  examine  platoon  level  tasks. 


LAWST  meets  this  requirement. 

26.  The  system  shall  allow  routes  to  be  adjusted  for  certain  time  periods  to 
support  branches  and  sequels  in  20  seconds  or  less. 


The  time  constraints  for  answers  during  a  wargame  are  generally  tight.  A 
logistician  needs  to  be  able  to  answer  questions  quickly  so  the  wargame  can  progress. 
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LAWST  meets  this  requirement. 

27.  The  system  shall  allow  logistics  assets  availability  to  be  adjusted  for 

certain  time  periods  to  support  branches  and  sequels  in  20  seconds  or  less. 


In  addition  to  the  structure  of  the  logistics  network  changing  during  the  wargame, 
the  location  of  assets  that  are  used  for  transportation  may  need  to  be  readjusted  to  support 
certain  branches  or  sequels.  Due  to  time  constraints  associated  with  the  wargame, 
outcomes  need  to  be  realized  quickly. 


LAWST  partially  meets  this  requirement.  Moving  assets  involves  going  into  each 
logistics  node  and  adjusting  the  number  of  assets  in  each.  This  could  take  a  few  seconds 
to  several  minutes  depending  on  the  number  of  adjustments  that  need  to  be  made. 


Analysis: 

The  system  shall  provide  the  following  analysis  within  10  seconds  when  any  changes 
are  made  to  the  Logistics  network: 

Determine  agility  of  the  logistics  network'. 

28.  -The  system  shall  determine  the  amount  of  time  it  takes  for  the  network  to 
recover  to  the  objective  DOS  on-hand  after  the  loss  of  transportation 
assets  or  closure  of  an  arc. 


Recovery  of  the  logistics  network  after  a  major  change  is  a  good  indicator  of  how 
robust  the  network  is  and  how  agile  the  response  to  issues  in  the  network  is. 

LAWST  meet  this  requirement.  This  can  be  done  with  LAWST,  scripted 

sorties  allow  unscheduled  assets  to  deliver  supplies  but  there  is  no  function  to  remove 
assets  or  routes  at  a  given  time  during  the  simulation. 

29.  -The  system  shall  determine  the  DOS  at  each  friendly  unit  in  excess  of  the 
objective  over  time. 

Delivery  of  supplies  is  generally  not  exact,  with  respect  to  the  amount.  Sometimes 
units  request  additional  supplies  for  certain  times  and  places;  other  times  like  during 
movement,  they  only  want  the  basic  3  DOS  on  hand.  It  is  important  to  determine  where 
the  supply  network  can  flex  when  supplies  or  transportation  assets  may  be  lacking. 


LAWST 


|  meet  this  requirement.  The  algorithm  in  LAWST  only  fills  units 


to  the  objective  DOS  as  specified  by  the  operator.  Excess  supplies  are  not  dehvered. 
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30.  -The  system  shall  determine  the  utilization  rate  of  transportation  assets 
within  the  logistics  networks. 

Flexibility  requires  that  options  can  be  determined.  High  utilization  rates  are 
important  to  identify,  this  signifies  that  there  is  little  availability  to  surge  additional 
supplies  in  a  given  area. 


LAWST  meets  this  requirement. 

31.  -The  system  shall  determine  the  number  of  excess  transportation  assets 
within  the  logistics  network  over  time. 

This  requirement  is  similar  to  30. 


LAWST  meets  this  requirement.  This  requirement  may  be  merged  or  rectified 

with  requirement  30  after  some  trade-offs  are  made. 

Determine  efficiency  of  the  logistics  network: 

32.  The  system  shall  determine  the  efficiency  of  the  network  with  respect  to 
number  of  transportation  assets  used. 

Logisticians  may  want  to  use  fewer  assets  if  possible,  to  reduce  costs. 


LAWST  meet  this  requirement. 

33.  The  system  shall  determine  the  efficiency  of  the  network  with  respect  to 
fuel  used  to  distribute  supplies. 


Logisticians  may  want  to  determine  the  most  efficient  network  with  respect  to 
fuel  used  during  operations.  This  is  also  a  key  question  that  E20  is  interested  in. 

LAWST  meets  this  requirement. 

34.  The  system  shall  determine  the  efficiency  of  the  logistics  network  with 
respect  to  an  estimated  cost  of  fuel  used  to  deliver  supplies. 

It  is  important  to  look  at  the  estimated  cost  of  an  operation  with  respect  to  the 
amount  of  fuel  used.  This  is  an  important  metric  to  determine  savings  for  one  COA  vs. 
another. 


LAWST 


|  meet  this  requirement. 


Determine  fuel  used  by  each  type:  priority  information  for  E20 
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35.  -The  system  shall  determine  the  fuel  used  by  each  distribution  node  in  the 
network. 

36.  -The  system  shall  determine  the  fuel  used  by  each  platform,  both 
maneuver  and  logistics  platforms. 

37.  -The  system  shall  determine  the  fuel  used  by  each  type  of  platform. 

38.  -The  system  shall  determine  the  overall  fuel  used  over  time. 

39.  The  system  shall  estimate  the  cost,  in  terms  of  estimated  dollars  and  fuel 
costs  to  execute  each  COA. 

For  requirements  35-39,  it  is  important  to  determine  where  the  greatest  impact  is 
with  respect  to  fuel  usage. 

LAWST  partially  meets  (5)  these  requirements.  Formatted  reports  are  not  built 
into  LAWST,  however  the  data  is  available  after  the  simulation  is  complete. 

Identify  Issues: 

40.  The  system  shall  determine  where  assets  are  insufficient  to  provide  the 
objective  DOS  within  the  logistics  network. 

It  is  important  to  pinpoint  where  the  logistics  network  is  weakest. 

LAWST  meets  this  requirement. 

41.  The  system  shall  determine  where  supplies  are  below  the  objective  DOS 
within  the  logistics  network. 

Logisticians  need  to  determine  where  and  when  to  surge  supplies  to  keep  up  with 
demand. 


LAWST  meets  this  requirement. 


42.  The  system  shall  determine  where  supplies  are  insufficient  to  meet 
demand  within  the  logistics  network. 


Similar  to  requirement  41,  maybe  combine  during  requirements  trade-off. 


LAWST  meets  this  requirement. 


43.  The  system  shall  assess  and  identify  areas  of  critical  vulnerability,  what  is 
most  susceptible  to  interdiction. 
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It  is  important  to  examine  high  utilization  arcs  and  nodes  to  determine  which 
portions  of  the  logistics  network  is  most  critical  to  the  success  of  a  mission.  This  allows  a 
better  understanding  where  additional  redundancy  or  force  protection  is  required. 

LAWST  Joes  nj  meet  this  requirement.  While  a  deeper  analysis  can  be 
conducted  using  the  data  that  LAWST  produces.  The  risk  scores  help  to  determine  where 
utilization,  throughput,  etc.,  is  high  but  it  does  not  show,  for  instance,  where  a  high 
capacity  arc  with  relatively  little  throughput  could  be  lost  and  have  severe  impact  to  the 
logistics  network. 

Optimize: 

44.  The  system  shall  provide  recommendations,  based  on  excess  logistics 
assets  and  available  supplies,  how  to  improve  the  network  efficiency. 

With  the  complexity  of  any  logistics  networks,  a  logistician  needs  help  identifying 
options  to  best  improve  a  logistics  network.  With  the  number  of  factors  and  levels 
associated  with  these  networks,  there  are  thousands  of  options  to  improve  the  network. 


LAWST 


|  meet  this  requirement. 


45.  The  system  shall  provide  recommendations,  based  on  excess  logistics 
assets  and  available  supplies,  how  to  improve  the  network  effectiveness 
with  respect  to  delivering  objective  DOS. 


Similar  to  requirement  44,  it  is  important  to  determine  how  the  network  should  be 
optimized.  Logisticians  should  be  able  to  determine  which  factors  are  the  most  important 
to  their  commander  when  analyzing  a  COA.  This  requirement  may  be  combined  with 
requirement  44  in  requirements  trade-off. 


LAWST 


meet  this  requirement. 
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